GNOME Bugzilla – Bug 329940
Moving windows with shift is broken
Last modified: 2020-11-06 20:05:08 UTC
Please describe the problem: I found when upgrading to 2.13.x that there seems to be window gravity, or whatever it is called where you can push windows up against eachother with resistance, and I love it. However, I liked having windows 'snap' together with moving them and holding shift. The problem I am having is that the functionality of moving windows with shift is broken. It works, as in it snaps windows together, however it is not doing it right. Examples are I have window A that sits in the middle of my desktop. Well, what happens is I now have window B, that it's height is greater than the difference from the bottom of Window A to bottom of the screen. What should happen is that when I start moving window C down from the top of the screen is that it should snap to windowA, and as I drag it snap to the bottom of windowA, and then finally have the bottom of windowB snap to the bottom of the screen. Well what's happening is the top of windowB is snapping to the bottom of windowA instead of snapping to the screen. There is a lot of oddities with it as well, that I can't really describe. If I knew how I would attach a video of it occouring. Steps to reproduce: Actual results: Expected results: Does this happen every time? yes Other information:
I totally lost you on your description. You were talking about moving window C and then switching to saying window B was snapping. Maybe provide a couple before & after screenshots or something and then describe what you moved and how?
Sorry... windowC is window B. ASCII Drawing of snapping not working.... +----------------------------------------------+ | | | | | +----------------+ | | | WinA +---------------+ | | | | WinB | | | | | | | | +-----------| | | | | | | | | | | | +---------------+ | | | +----------------------------------------------+ (above: window B is startting to be dragged while holding shift.) Instead of doing the following (which should happen): +----------------------------------------------+ | | | | | +----------------+ | | | WinA | | | | | | | | +---------------+ | | | | WinB | | | +-----------| Snapped to | | | | bottom | | | | | | | | | | | | | | +-------------------+---------------+----------+ (above: what should happen first, the bottom of windowB should snap to bottom of the screen. However this is not happening.) It will act as following, not allowing the above senerio: +----------------------------------------------+ | | | | | +----------------+ | | | WinA | | | | | | | | | | | | | | | +-----------+---------------+ | | | WinB | | | | Snapped top | | | | to WinA | | | | | | +-------------------|---------------|----------+ (above: windowB snapps to the bottom of windowA, and loses half the content off the bottom of the screen.) Hope this helps.
I can't duplicate -- WinB always snaps to align with the bottom panel as I move down and then after I move later I'll have WinB snapped to align to WinA. How big are the two windows and where are they located (you can use xwininfo to find out)? How are you moving the windows? (Alt+F7? Click on titlebar then drag? Alt+click on the client area and then drag?) Where, approximately are you click on WinB to start the move operation? When do you press the shift key? Do you have any windows open other than these two?
Attached are 2 pictures. The screen has, XMMS, gnome-term, gaim and thunderbird. In the first screenshot (screenshot.jpg) Thunderbird is in the bottom left corner. As I drag thunderbird towards the right, it jumps all the way over not snapping to any other window in the screen. Well, it seems the database is broken to upload an attachment, so I will upload them shortly.
Created attachment 58728 [details] Picture1
Created attachment 58729 [details] Picture1
Created attachment 58730 [details] Picture2
Created attachment 58731 [details] This is a better depiction of the issue
Created attachment 58732 [details] Better depiction part 2
Weird. Can you get a verbose debugging log? To do so: 1. Reduce your desktop to as few windows as possible to reproduce the bug 2. Run METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1 metacity --replace 3. On stdout metacity will print the name of the logfile 4. Reproduce the bug as quickly as possible 5. Kill the metacity you started above to stop the logfile from growing any longer 6. Attach the logfile here
Created attachment 58734 [details] Verbose Log of the problem.
Any advances on this issue, or can I do anything to help the process?
I can't reproduce this with the most recent CVS build. Window B snaps to the bottom of the screen going down. It doesn't appear to snap its top to A's bottom at all on the way down, only on the way back up (I assume this is intentional).
(sorry, I totally missed reading the "and holding shift" part. My bad. I'm sorry.) I can't reproduce it here with the most recent CVS build even so. B's bottom snaps to A's bottom and then to the bottom of the screen.
Two mid-air collisions with Thomas now. Is he watching over my shoulder and submitting something just when I'm about to? :) Anyway, it's nice to know that I'm not the only one that can't duplicate this problem. David: What version of Metacity are you running? I think I might have a guess at the problem if you're using an older version... Anyway, I got busy with a bunch of other stuff so I haven't had time to look at it again yet. I looked over the log and realized I don't have extra debugging information added inside of the edge resistance code. So I need to add that when I get some more time and do so before 2.14.x just for sanity sake in general. If you're using a new version of Metacity and still getting this bug, I'll need you to send me a new verbose debugging log after I get that done. Alternatively, if you could find steps that would cause this bug to be 100% reproducible with the latest Metacity that'd be even better. I can't reproduce.
I can still reproduce, and I just checkedout from cvs again.
(In reply to comment #15) > What version of Metacity are you running? I think I might have a guess at the > problem if you're using an older version... Just fresh checked out of CVS > Anyway, I got busy with a bunch of other stuff so I haven't had time to look at > it again yet. I looked over the log and realized I don't have extra debugging > information added inside of the edge resistance code. So I need to add that > when I get some more time and do so before 2.14.x just for sanity sake in > general. If you're using a new version of Metacity and still getting this bug, > I'll need you to send me a new verbose debugging log after I get that done. Lemme know when your debugging is in CVS I will check it out again. > Alternatively, if you could find steps that would cause this bug to be 100% > reproducible with the latest Metacity that'd be even better. I can't > reproduce. I can write something about this and post it later, however it's time for class...yay learning :( Never let schooling interfere with your education.
Its been almost a week since any talk. I just updated from CVS again today, and still find the problem evident. Sorry I have not written anything detailed, but I have been overly busy. I was wondering if there has been any updates/changes/reproduction.
I just updated from CVS again today and still have the problem. I guess something to try is have a window like xmms open and have it on the right side of the screen, then have another window like gaim open on the other side of the screen. Then take a terminal and put it smack dab in the middle, then open a gaim conversation window and try moving it around with holding shift. That's the only time I see the problem. Any other updates?
I started writing a patch with the extra necessary debug info, but have not had much time and didn't complete it. So I haven't forgotten about this, I've just been really busy. Thanks for being patient; I'll try to get this done with enough time before hard code freeze that we can find the problem.
It's been another week. Any updates? Is the code put in to debug. I don't think I noticed it in todays CVS update I did. Anyways, it's not looking good to have this fix in the 2.14.0, so maybe we can get this set for 2.14.1.
Created attachment 60740 [details] [review] Add debugging information for edge resistance Sorry, I've had a bunch of craziness that wasn't supposed to happen for an extra week and a half hit me a while ago; anyway, here's a patch to add debugging info that should help track this down and let me know what's going on. Could you try running with it and getting a verbose debugging log? I'll try to look at it when I can; it'll almost certainly be 2.14.1 material, though.
OK I added your patch and re-ran with the cli options. And I am posting the output.
Created attachment 60755 [details] New Log with more debugging
Created attachment 61812 [details] log of a 2.14 checkout (3-22@7:29EST)
The above log was a log that I just ran again. I want to note something new I found. This problem I have been having --ONLY-- occours when BOTH gaim and XMMS are open and attached to both ends of the screen. Hope this helps in the debugging. (see attached pictures for details) (also note...screen resolution = 1280x1024)
Sorry for being so slow at getting back to this. March has been crazy... How did you create the most recent logs? The string "EDGE_RESISTANCE" doesn't appear anywhere in the log, so either you weren't running in verbose mode (i.e. you missed part of the steps from comment 10), or you weren't running with a version of Metacity with this patch applied. Your screenshots look pretty wide -- are you using xinerama? Also, your screenshots show lots of extra windows being open. Can you try closing (which does not mean minimizing) ALL windows except the ones needed to duplicate this bug and verify what a minimal setup needed is? If you are using xinerama, can you duplicate this with all windows on just one of the monitors and no windows touching the side of that monitor adjacent to the other one? Can you take a new screenshot of the minimal setup (before the bug) and then describe which window in that screenshot you will move to get the bug? In addition to the screenshot, can you also run xwininfo | grep -A 2 upper-left and then click on one of the windows. Then repeat for the other windows and post that information here? If you post a new debugging log, it'd be great if you could do so only when running with such a minimal setup. Thanks for all the work to track this down.
Created attachment 70238 [details] image of another window configuration in which the edge-snapping code misses the screen border I just managed to reproduce this bug. In the attached image there are three gnome-terminal windows. First there is a big one maximized, on top of that there is another one in the top-left area. Its left border is aligned to the screen edge and its top border is ~25 pixels down from the top screen edge. The third window is focused and it is very tricky making it snap to the top screen edge if you just move it "northwards." Instead of snapping to the top screen edge, its bottom edge snaps to the bottom edge of the gnome-terminal window above it. Maybe it has something do with me and David having very large screen areas? I have 1920x1200 (no xinerama) and David have 2560x1024 (with xinerama it seems). I have only tried with Metacity 2.14.5
Maybe, but I just tested again with new CVS and it's still there. I also tried it running with 1024x768 without XINERAMA and can still reproduce. Any updates.
After nearly 3 years, and metacity not being the default window manager this can be closed. (whoever wants to close it)
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.