GNOME Bugzilla – Bug 761760
Welcome graphic and heading is misaligned
Last modified: 2016-08-02 19:20:42 UTC
Created attachment 320703 [details] screenshot Testing 3.19.x with GNOME Continuous from four days ago: the content of the welcome screen isn't centered. The whole thing looks like it is shifted too far to the right. See attached screenshot.
(In reply to Allan Day from comment #0) > The whole thing looks like it is shifted too far to the right. Mmmh, that actually looks like the position would be correct if the room list was visible.
(In reply to Florian Müllner from comment #1) > (In reply to Allan Day from comment #0) > > The whole thing looks like it is shifted too far to the right. > > Mmmh, that actually looks like the position would be correct if the room > list was visible. In-app notifications are also misaligned by the same amount - so it's not just the graphic that's effected.
Wait, in-app notifications? I don't see a case where we would show a notification in the empty state, so something's really fishy there. Maybe there's something in the journal that helps figuring out what that might be? (For what it's worth, I'm not seeing that issue when I disable all accounts - the sidebar is properly hidden here and the placeholder centered)
(In reply to Florian Müllner from comment #3) > Wait, in-app notifications? I don't see a case where we would show a > notification in the empty state ... Try removing the only connection: Polari reverts to the empty state and shows a "connection removed" in-app notification.
Created attachment 321582 [details] Screenshot after removing a connection (In reply to Allan Day from comment #4) > Try removing the only connection: Polari reverts to the empty state and > shows a "connection removed" in-app notification. Yes, but both placeholder and notification are properly centered for me in that case - see screenshot. I did download the continuous image now, I'll try to reproduce the issue with that later (got to commute to the office and take care of mutter/gnome-shell releases first though)
I suspect this is a GTK+ issue - I can reproduce the issue when I disable animations (as is default in a VM). Somehow the sidebar is *drawn* correctly (read: slid out), but takes up the space as if it was revealed.
Created attachment 321600 [details] Reproducer for the issue
Created attachment 321603 [details] [review] revealer: Don't assume a child orientation for 'none' transition It is safe to assume that the child should shrink vertically when the transition is a vertical slide (up or down), and horizontally for a horizontal slide (left or right), but picking one direction when there is no transition is problematic - in that case the child should either be fully visible or fully hidden, no matter its actual orientation. Simply allowing the child to shrink in either direction should be much more likely to get us the expected result.
The attached patch fixes the issue for me, but triggers some warnings in testrevealer, so suggestions welcome.
Created attachment 321649 [details] photos screenshot Looks like this issue is affecting Photos too.
The problem with that patch is that you now don't have any size to base the child size on -- i.e. the problem is that there's no TRANSITION_TYPE_NONE_VERTICAL vs. TRANSITION_TYPE_NONE_HORIZONTAL :) One potential way around this is another case in gtk_revealer_get_child_allocation that just sets both heigth and width of child_allocation *and* Florian's patch, so the minimum size of the child is kept when allocating it, but the preferred size of the revealer shrinks to 0.
Created attachment 321653 [details] [review] revealer: Don't report >0 preferred width... ... if the child is concealed and the transition type is set to NONE. In this case, both preferred width and preferred height should be 0, but we still can't use that to allocate a size for the child, so care about the minimum size of the child in gtk_revealer_get_child_allocation.
We are seeing something similar in Maps, but we have TRANSITION_TYPE_SLIDE_LEFT... it is the bug: https://bugzilla.gnome.org/show_bug.cgi?id=762442
I was under the impression that all these "continuous only" bugs exist because Continuous doesn't do transitions, so all revealers are automatically TRANSITION_TYPE_NONE.
(In reply to Timm Bäder from comment #14) > I was under the impression that all these "continuous only" bugs exist > because Continuous doesn't do transitions, so all revealers are > automatically TRANSITION_TYPE_NONE. A might be, I will give your patch a spin to see if it fixes this. And yes my case is under Boxes and VirtualBox where gtk-enable-animations is FALSE so that might equate TRANSISTION_TYPE_NONE?
Should be, since the effective transition is _NONE in case gtk-enable-animations is FALSE: https://git.gnome.org/browse/gtk+/tree/gtk/gtkrevealer.c#n297
It did the trick! Thank you! With that patch the sidebar-revealer behaves fine in VirtualBox!
*** Bug 762442 has been marked as a duplicate of this bug. ***
*** Bug 760317 has been marked as a duplicate of this bug. ***
Patches seem to work fine to me. It would be great to add test testcase to tests/ in gtk+ too, just so we keep it around
Review of attachment 321603 [details] [review]: ok
Review of attachment 321653 [details] [review]: ok
fwiw you can see the effect in tests/testrevealer already since now clicking on the "None" button in the upper left or on the "Right" button in the center left resizes the window by a few pixels, which it previously didn't because the None revealer in the upper left still requested the entry's size. After writing that patch I did however also write this test case: http://paste.fedoraproject.org/325861/00264145/ but Benjamin told me I could have as well written a few ref tests
Attachment 321653 [details] pushed as 0c25c5d - revealer: Don't report >0 preferred width...
*** Bug 769424 has been marked as a duplicate of this bug. ***
Hi, this bug was triggered here in Ubuntu GNOME 16.04.1 LTS by gnome-maps 3.18.3. Please cherry-pick the commit to the gtk-3-18 branch.