GNOME Bugzilla – Bug 353363
[regression] Moving windows across workspaces with the mouse
Last modified: 2011-01-20 10:12:01 UTC
Using the metacity version that came along with gnome 2.14 (and all those before as far as I can remember), I was able to do the following: _ Have my workspace-switching shortcuts assigned to ALT+<workspacenumber> _ ALT + <click on a window> + <workspace number> would switch me to that worskpace and move the selected window too. With the 2.15 series: _ The workspace switching alone works (ALT + <workspace number>) _ Moving a window within a workspace still works (ALT + <mouse button>) _ The combination doesn't allow me to move a window to another workspace.
I'd call it random "luck" which was almost certainly due to other bugs that metacity <= 2.14.x behaved that way. There are "move_to_workspace_<n>" window keybindings specifically for moving the currently active window to the nth workspace.
I know there are zillion of other ways of doing the same thing, but none as fast/efficient as that one and that combine the two features :( The existing "Move to workspace n" shortcuts only move the window to that workspace, they don't switch the view to that workspace (your window goes away AND THEN you have to switch workspace).
hi all. good to see the thing reported already. upgraded to 2.15.34 on ubuntu/edgy this evening, and immediately stumbled across the very same issue after the following login. i comment to state that agree very much with edward: personally, i'm not interested on what options are left to do the same thing. i'm aware that it remains possible to move windows across workspaces, otherwise severity would rise a little, right? said behavior used to be perfectly intuitive. it has worked for years. including metacity from its earliest releases. it used to work with sawfish. it used to work for any enlightenment releases shipping with ancient gnomes another bunch of years before. it used to work on fvwm, i suppose, if i only could remember correctly. rest assured there is a ton of users depending a lot on exactly the same behavior. alt-n has been default setup for workspace switching for ages now, whether metacities defaults set it up or not. workspace switching while dragging is clearly a regression in the bread-and-butter area. kind regards, daniel
(In reply to comment #1) > I'd call it random "luck" which was almost certainly due to other bugs that > metacity <= 2.14.x behaved that way. There are "move_to_workspace_<n>" window > keybindings specifically for moving the currently active window to the nth > workspace. > Elijah, Any hints as to which bugfixes would have removed that *feature* ? I'm going through the whole 2.15 changes, but the code has changed quite a lot so it's hard to pinpoint. If you could hint to a smaller area I could figure out the problem and propose a patch.
This wasn't random luck, it was how I used WindowMaker which I was using at one point before writing metacity; it's why the original metacity workspace keybindings were alt+number. Most people at the time used alt+number in xchat though, is why those aren't the defaults as they were in windowmaker. Well, I don't do it quite like the original poster; I just click on the titlebar then alt+number, rather than alt+click+number anyway, people there is no need to "lobby" on bugs, just add factual info if any is missing... once someone figures out which change caused this it can be evaluated whether it's hard to fix without breaking another fix, or not.
(In reply to comment #4) > Elijah, > Any hints as to which bugfixes would have removed that *feature* ? I'm going > through the whole 2.15 changes, but the code has changed quite a lot so it's > hard to pinpoint. If you could hint to a smaller area I could figure out the > problem and propose a patch. Ooh, after thinking about it for a minute I think I know the cause. In #126497, we did a keyboard grab for mouse-only actions in order to allow the move/resize event to be undone by hitting escape. Because of this, keyboard actions pressed during such a grab enter metacity/src/keybindings:meta_display_process_key_event(), go to process_mouse_move_resize_grab() which only checks for the escape key, and then breaks out without checking for other keypresses. This happens to have the nice side-effect of disabling nonsensical actions (e.g. Alt+F2 to launch a run-application dialog or Alt+F1 to focus the panel) during a window move/resize. Unfortunately, it also currently disables extra stuff, which apparently was intentional. So, we just need to categorize which actions make sense, and then make sure they are checked instead of blindly ignoring everything except for escape keypresses.
Stinking commas. Probably not clear even when it's pulled out. Anyway, change "disables extra stuff, which apparently was intentional" to "disables extra stuff which apparently was intentional [and that therefore shouldn't have been disabled]".
*** Bug 355463 has been marked as a duplicate of this bug. ***
Created attachment 75592 [details] [review] Patch to revert #126497 patch for 2.16.3
I am really fond of this feature and hence created the patch above to revert the bug fix. I probably never saw the bug it was trying to fix, so it is worth it to me. I have tested it, and it does restore the grab window and switch workspaces feature.
See comment 6 for the correct fix. In particular (with some added clarification): So, we just need to categorize which [keybinding] actions make sense [during move/resize grab operations], and then make sure they are checked instead of blindly ignoring everything except for escape keypresses. The first step, is going through all possible actions and categorizing them; may require consulting some usability folk.
I more added the patch for people who wanted at workaround while they wait for the real patch.
*** Bug 356608 has been marked as a duplicate of this bug. ***
Is this every going to get fixed? I am up to 2.18.0 and this feature is still broken. I am still have to use the patch to get things working.
after almost a year of patient perserverance, i would not say that i feel disgusted. it's not like the fact that a patch (which does not look particularly wild, as far as i can tell) has been available but remains consistent in its permanent state of being-ignoredness, well, like it makes me sick or something. no. it's much more fundamental. what i feel is that, after a year of missing that feature, i still find it hard to get used to it. it sucks. sucks. sucks. sucks. it's not going to get any better. right clicking and strolling through 2 levels of context menus is slow. tedious. it won't get any better. i tried to practice. i thought i would at some point understand why it had to go. maybe if i try to convince my self that it's not gone by accident, which it apparently did, but for a good, particular reason. maybe like it had to go because that's how time goes by, that it's a matter of live or something. that its disapperance would pave the way for something new and unimaginable. but it's not happening. and i won't get used to it. i remember, it ued to be so quick and intuitive, back in the days. it's gone. so much time. mama. it still feels wrong. i know it won't get fixed, but ...
1) there is no patch, just a workaround that breaks something else. 2) nobody disagrees that this is a bug, that's why the bug is open. 3) there are also hundreds of other bugs open just for metacity, and thousands on gnome.org in general. many of them are equally worthy. some get closed every day, but there aren't enough people to get ahead of them all. anyone is welcome to write this patch and fix the bug. Elijah even explained how above. If you aren't willing to do it yourself, then you have to wait for a volunteer who has time. Or pay someone I suppose (I am not offering, but there are people who probably would do it on that basis). adding comments isn't really going to help. what will help is doing the work. And yes, I personally added this feature originally, and I miss having it. But I don't have time to fix it again, and so I'm not going to sit here and whine about it when nobody else has time either.
Ok, I decided to try to solve the problem on my own, and I seem to have come up with a simple solution. In keybindings.c's process_mouse_move_resize_grab the end is /* The keypress really isn't handled but we just want to ignore it, so * treat it as handled. */ return TRUE; I created a patch to remove the comment and change the return to FALSE. The grab and switch feature works again while keeping the feature to reset resize and move with escape. So this seems to give of the best of both worlds. What are the down sides? If there are serious down sides, why are we trading useful feature like easy moving of windows around for a feature to reset resize or move? Like it really matters if a window goes back to it's precise original size or position. It is trivial to just resize it again or move it again.
Created attachment 89135 [details] [review] Patch to make both features work with a simple change
I think I fooled myself. The patch doesn't work. Going to work on another patch.
Ok, I took some time and really dug into the code. What I found is that at least the way the code is currently written these features are directly opposing. The old feature expects to be able to do a keyboard shortcut while holding the window with the mouse pointer. The new feature expects to be able to do an explicit key while holding the window with the mouse pointer. By explicit, I mean it isn't doing a keyboard shortcut, hence the key isn't universal. Since it isn't universal it "grabs" the keyboard and hence blocks all keyboard shortcuts. This is try, because metacity, being a window manager is in a special case. Normally the key, escape, would go to the window, say a terminal. Without keyboard shortcuts you can't switch workspaces with the window. I am going to look further into what it is going to require.
*** Bug 474195 has been marked as a duplicate of this bug. ***
Review of attachment 89135 [details] [review]: (poster says patch doesn't work, taking it off the review queue, sorry for spam)
Oh hey, this is a nice old bug I forgot I was watching. FWIW, this works these days in modern metacity. I'm using 2.30.3 which shipped with Fedora 14, but IIRC, my muscle memory went back to click-alt-F4ing years ago, so it's likely been fixed for much longer.