GNOME Bugzilla – Bug 741374
HiDPI - Applications with headerbars leave a gap when half-maximised (side-docked)
Last modified: 2014-12-15 22:16:04 UTC
Created attachment 292507 [details] Headerbar docking issue When applications with header-bars are docked to the side (i.e. half-maximised) they leave a pretty thick gap on all of its sides, but applications with conventional titlebars dock correctly. Versions of libraries being used are as follows: gtk 3.14.5 clutter 1.20.0 cairo 1.14.0 mutter 3.14.2 gnome-shell 3.14.2 Screenshot in attachment shows gnome-terminal and nautilus, both half-maximised, but the issue seen with nautilus is more general and applies to all applications with the header-bar (gnome-documents, etc.)
this is under wayland ?
No, this is under Xorg.
Created attachment 292510 [details] Gap in highlight effect in activities overview In fact, the issue is not just while docking -- a generous gap also is seen in the highlight effect in activities overview, and while dragging the application window to the top to maximise it, the dragged window stops just short of the top-bar, but it maximises just fine despite that.
hmm, thats certainly not happening here
Ok, so it might be something to do with my setup: I have updated cairo to 1.14.0, then rebuilt clutter and gtk+ against this updated cairo to get HiDPI support on my computer. Is there anything else I need to rebuild against the updated cairo to fix this?
likely: clutter, mutter, and gnome-shell.
(In reply to comment #6) > likely: clutter, mutter, and gnome-shell. Rebuilding mutter and gnome-shell against cairo 1.14.0 did not improve the situation (I already had clutter built against cairo 1.14.0 as reported originally).
Hi Emmanuele! I think the problem may have been caused by this patch https://git.gnome.org/browse/gtk+/commit/?id=8753ef612940d5977bc8af2cca3ceb6cc669d1e4 which, although from master, applied cleanly against 3.14.x too, and I had that in my tree. Removing that patch corrects this problem, but takes me back to having no-shadows on half-maximised windows, which is very difficult to work with. Please let me know if this patch might have been the source of the problem (or it could simply have been updating from 3.14.5 to 3.14.6). Oh, and this bug can be closed now, I think. Thanks a lot.
Created attachment 292777 [details] Screenshot showing attempt to maximize nautilus window stops before top-bar I don't think the bug as a whole is resolved. Although side-docking now works, the other issues still remain, namely: 1. Drag-resizing windows (with headerbars) stops well before the top-bar 2. While attempting to drag-maximize the window, dragging stops short of the top-bar (screenshot attached) 3. Highlight border in application-overview when hovering over windows with headerbars leaves considerable gap (not seen with conventional title-bar-windows). I wonder if it might be the right thing to do if I change the summary accordingly and reopen? Or should I file a separate bug?