GNOME Bugzilla – Bug 672543
keyring dialog too big
Last modified: 2013-07-02 21:50:36 UTC
Here is what I see with .92
Created attachment 210227 [details] screenshot
Also see https://bugzilla.gnome.org/show_bug.cgi?id=652459#c13. I'm pretty sure that this is a problem with StTable not handling size requests of height-for-width actors correctly - in short, the checkbox' height is based on the natural/minimal width of the entry ("the widest actor in the column"), not the actual width we end up allocating. For 3.4, I'll take a look at the corresponding code in MxTable/ClutterTableLayout, but longer term, my preferred approach would be to subclass ClutterTableLayout (to account for children's CSS properties) and use that in StTable (so we can leave the actual layout logic to the existing ClutterLayoutManager and just keep the widget for convenience/compatibility).
*** Bug 672149 has been marked as a duplicate of this bug. ***
I can reproduce this; note that as soon as you start typing some characters in the dialog, its height will shrink down (if you then delete characters, the height will turn back to the initial size again).
Created attachment 210496 [details] [review] st-box-layout: Don't bypass Clutter's size negotiation For horizontal box layouts, we assume children will be given their preferred width when querying them for their height. While this assumption makes some sense when considering a single box with its children, it interferes with Clutter's size negotiation when dealing with nested BoxLayouts of different orientations. Apparently I was wrong in blaming StTable. This patch fixes most of the problem for me - there is still some shrinking when underallocating the entry (e.g. entering more characters than which fit the width), but it is a definitive improvement over what we have now. Still, I'm not quite happy with the patch - it feels dirty to get rid of the enforced -1 for_size in get_content_preferred_height(), but not in get_content_preferred_width(). Unfortunately the latter breaks quite spectacularly, so I'm leaving that out for now. I think it should be possible to come up with a keyringPrompt-specific work-around in case we consider this patch too risky at this point - I'm sure the change is correct, but there might be places where we rely on the current behavior which I missed in testing. Opinions?
Created attachment 210606 [details] [review] checkBox: Work around a height-for-width problem StBoxLayout currently does not handle height-for-width children correctly under some circumstances. As a work-around, hard-code a label height of two lines of text, which should work for most locales in the one place the widget is currently used. Quick and dirty work-around, in case we discard the fix as too risky.
Review of attachment 210606 [details] [review]: Yeah, let's go with this.
Comment on attachment 210606 [details] [review] checkBox: Work around a height-for-width problem Attachment 210606 [details] pushed as bf99298 - checkBox: Work around a height-for-width problem Pushed with release team approval.
Let's mark this as fixed for now. We can review the rest of the stuff for the 3.6 cycle (including porting to ClutterBoxLayout and all that fun stuff)
(In reply to comment #9) > Let's mark this as fixed for now. We can review the rest of the stuff for the > 3.6 cycle (including porting to ClutterBoxLayout and all that fun stuff) I think the first patch is still worth considering for 3.4.1, see http://mail.gnome.org/archives/release-team/2012-March/msg00301.html (obviously moving to ClutterBoxLayout or anything is out of the question pre-3.5)
*** Bug 644667 has been marked as a duplicate of this bug. ***