GNOME Bugzilla – Bug 760482
GtkFrame cuts off bottom 2 pixels of child
Last modified: 2016-02-29 23:50:14 UTC
shadow-type = none: https://i.imgur.com/deDK21q.png shadow-type = anything else: https://i.imgur.com/ALg29wY.png Adding frame > * { padding-bottom: 2px; } seems to make things look right, but mattias says that's just a workaround and not an actual fix. Running gtk master.
Yeah this looks way too hacky to me too :-/
Is this still the case with master? Ive fixed another frame size.allocation bug recently.
Still the case.
Note that for your particular case, there is no good reason anymore to have a GtkFrame there at all - just let the scrolled window draw the border around the list.
I haven't been able to reproduce this problem with my testcases, and I don't know how to make that listbox appear in the maps popover. Can you provide a testcase ?
Created attachment 319401 [details] test case If you run with GTK 3.18 then the popover changes size to accommodate the change in GtkFrame size. With GTK 3.19 the popover doesn't change size and instead the contents of the GtkFrame have less room. The effect is emphasized if you increase the border-top-width css property of the GtkFrame.
Still need a reproducer that works on my system, I'm afraid
The test case doesn't work for you? This is how it works on my system: http://webm.land/media/ZY67.webm I'm running an entirely up-to-date jhbuild moduleset. On the left is 3.19: jhbuild shell; gjs main.js On the right is 3.18: gjs main.js (enlarged to better show differences) Toggling the frame on the right changes the size of the popover Toggling the frame on the left changes the size of available room for the Frame's child. You can see on the left that the button is 2 pixels too-close to the frame when the frame is visible.
no, it works
*** Bug 762072 has been marked as a duplicate of this bug. ***
Created attachment 322393 [details] [review] frame: Measure border gadget separately
Created attachment 322394 [details] [review] frame: Let GtkContainer handle border-width
Created attachment 322398 [details] [review] frame: Let GtkContainer handle border-width
Created attachment 322399 [details] [review] frame: Measure border gadget separately
Created attachment 322401 [details] [review] frame: Measure border gadget separately
Review of attachment 322398 [details] [review]: seems to work well
Review of attachment 322401 [details] [review]: yes, looks fine
Pushed, thanks.
(In reply to Matthias Clasen from comment #18) > Review of attachment 322401 [details] [review] [review]: After these changes the settings window has been extremely high. And I can not reduce the size of the window. http://storage1.static.itmages.ru/i/16/0226/h_1456481342_2938878_47a665e193.png
I can't really judge from that screenshot what app it is or if not one of the other tabs is causing the window size. Is there another place this is happening?
(In reply to Timm Bäder from comment #21) > I can't really judge from that screenshot what app it is or if not one of > the other tabs is causing the window size. Is there another place this is > happening? Sorry. I forgot to specify that it is the DeadBeeF player settings window. I see this problem only in this application. I am trying to understand what the problem is.
http://storage3.static.itmages.ru/i/16/0226/h_1456486436_3607236_f26cc4e318.jpg
Ok thanks, I can reproduce and will hopefully find time to look at it later today.
Created attachment 322462 [details] [review] frame: Fix horizontal size request We were adding the border gadget size and the label widget size in any case, but when calculating the width, we want the maximum of those two, not the sum.
(In reply to Timm Bäder from comment #25) > Created attachment 322462 [details] [review] [review] > frame: Fix horizontal size request > > We were adding the border gadget size and the label widget size in any > case, but when calculating the width, we want the maximum of those two, > not the sum. Thanks. It's working again.
Review of attachment 322462 [details] [review]: yes