GNOME Bugzilla – Bug 304927
Weirdness in the shaken_loose code
Last modified: 2020-11-06 20:05:10 UTC
It would be great if a maximized window could be resized using the usual alt+right mouse button action. Right now, resizing a maximized window needs 2 actions: Restore it somehow, then resize. Or is this supposed to work already? The mouse cursor is already changed to a resize cursor. (Then this report should be changed to "bug")
Weird, I had never tried it (I don't use maximized windows), but I had assumed the "shaking loose" stuff would work for resizing windows too; apparently it was only for moving windows (see bug 115000). The cursor does change to make you think it can resize, when it doesn't allow you to, so there's definitely a bug.
*** Bug 315622 has been marked as a duplicate of this bug. ***
So, I'm combining a couple of the bugs about the weirdness of the shaken_loose code into here. The shaken_loose code allows a window to be unmaximized by moving it around (huh?) and the code has the following properties: - It seems to hardcode for the case of two xinerama windows in a horizontal position relative to each other and where there aren't any partial struts. - Even in the case it hardcodes for, it surprises people -- see bug 315622. The arbitrary choice of doing this only for y movement seems weird. - I personally don't see how it makes any sense in the common single xinerama case. - It looks buggy if there's a partial strut at the top of the screen ("why can't I move my unmaximized window into that freespace at the top? Why is it re-maximizing when I haven't touched the panel?") - It doesn't make any sense why this applies to only moves and not resizes (which is what this bug was originally about before I extended it) - It mucks with display->grab_initial_window_pos, which is supposed to mean the _original_ position of the window. This causes problems, for example, with allowing the Escape key to undo moves & resizes. Try it -- Alt+F7, move the mouse around for a while and then hit Escape. Ewww. (See also bug 126497). If the code remains, it should be fixed to not muck with display->grab_initial_window_pos and handle partial struts, and get some usability feedback on the other issues. Personally, I'm all in favor of nuking it. Objections? Alternate suggestions?
I would nuke it. Does anyone really use this? (I will ask on p.g.o.)
Should look at the original bug/discussion about adding it probably, I don't remember what was there. It always seemed to me that it would only kick in if you tried to move a maximized window, so if you just don't think to do that (and unmaximize, then move) you would not see this feature. The main point iirc was moving between xineramas while keeping the maximized state, but I could be wrong.
Please do not 'nuke' it. I don't know what kind of crazy hacks he had to use, but I find it very handy.
moving between xineramas I think is the most compelling use of this; not much reason for it to exist independent of xinerama. But it's exceptionally handy for xinerama setups. Whenever I'm on a multi-head windows box it makes me pine for metacity when I want to shift windows between screens.
FWIW, I know some more people who uses this and I happen to use it sometimes. It's also a great feature neither Windows nor OSX has. I think we should keep it. Thanks,
Heh, didn't know about this till now, but it is something I would use.
I use the feature a lot. It is very discoverable in the Xinerama case: I have a maximized window on this screen, but I want it on that screen, so I try to drag it.
Huge chorus of dismay about the idea of removing it on my post: http://marnanel.livejournal.com/869763.html
Moving windows from one xinerama display to another is what I do frequently, too. When moving the maximized window directly horizontally without "shaking loose" there is a bug described and solved(?) here http://bugzilla.gnome.org/show_bug.cgi?id=358715 I'm not sure if it is a dirty hack or if it's okay. It was the first time looking into the metacity sources for me. There are some design problems with xinerama and moving windows around in general. It looks like the center of the window determines to which xinerama display the window "belongs". After having shaken loose a maximized window, a user would expect that remaximizing will occur on the display where the cursor is (and not the window center). For this reason, the current metacity code sets the saved_rect position to the top left of the xinerama workspace the cursor is in, then unmaximizes the window and then maximizes it again. This yields an unexpected saved_rect position for a relatively small window being moved from the right monitor to the left monitor. When the user unmaximizes it, he founds it on the top left position of the workspace. However, the user would expect it on the right side of the left workspace because he moved it from the right monitor to the left.
To get this back on track a bit, please take a look at bug 346347 ("resize maximized window using alt+middle mouse button"), which I posted after this bug got lost in the debate about the shaken_loose code. Actually my first report doesn't have to do anything with the discussion at all (from comment 2 on). The title of the bug was also edited by someone else. Unfortunately I mentioned a right mouse button + alt key combination, but meant a middle mouse button + alt.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.