GNOME Bugzilla – Bug 611004
Make GtkFrame good for both design and accessibility
Last modified: 2017-03-06 14:16:22 UTC
There is a gap in current GTK+ that could be good to fix for 3.0
In past years we had two opposing, but valid, needs/suggestions:
1) don't use GtkFrame for design - see HIG, bold + spacing is better for visual
2) use GtkFrame for a11y - "This enables users to navigate between entire
sections of UI rather than just field-by-field." (from )
While the latest GtkFrame is able to hide the "frame", it seems to me there are at least some pending spacing/padding issues: for example, using glade-3 to add a GtkFrame, it seems there is 1 pixels border all around, as well as the 6 pixels spacing between the title label and the topmost children widget should manually added.
So, can we check and in case fix GtkFrame to accomplish both needs? I.e. make GtkFrame a painless widget to use, just add to you project and consume it adding children, without worrying about actual appearance or other compliance to GNOME HIG.
Of course later we'll have to sponsor and convince developers to switch back to it :)
Yes, now I remember the other issue in GtkFrame: colors. In some themes there were used different colors for frame background and for frame child background.
Of course this is related to historical issues in gtk+ theming, I know...
Created attachment 154625 [details]
Screenshot of GtkFrame in glade-3 with spurious 1 pixel border
I second the suggestion to improve GtkFrame in such a way that it can more easily be used. Design shouldn't be hardcoded in the source. And adapting GtkFrame in code is ugly and also wrong on some platforms.
The problem is that GtkFrame has a double role as a visual group for controls and as a visible frame.
Suggestion a: Introduce a new widget, GtkWidgetGroup, which has properties label, label-widget and style properties label-bold, label-xalign, label-yalign, shadow-type. Themes would determine the appropriate padding. The existing GtkFrame would continue to be used as a visual frame.
Suggestion b: Add new style properties mode, label-bold and shadow-type. "mode" here is an enumeration of GTK_FRAME_VISUAL, the current behaviour and GTK_FRAME_GROUP, meaning that the new style properties take effect.
I'm leaning towards a) since themes should be able to clearly distinguish the different cases and it feels awkward to add a mode. The names sprang out of a 2 minute braincloud, so there might be better ones.
I don't think this is relevant now. Style properties are a no-no, and CSS styling can effortlessly bolden the label and add space between it and the child (and there's the widget property label-xalign for the rest).
Also, while the HIG should be followed, I'm doubtful that we should (or do anywhere else) enforce its guidelines in default constructed widgets.
Styling the label or child widgets doesn't necessarily require adding specific classes from code, as general selectors ought to cover most cases: To style the label, select on frame > label. To style the child, select on frame > :not(label):not(border)
That said, if you add a custom label-widget that isn't a GtkLabel, and/or your main child IS (also) a GtkLabel, this might be trickier... see https://bugzilla.gnome.org/show_bug.cgi?id=778771
If there is still any spurious padding anywhere, then a specific new bug could be opened.
(In reply to Daniel Boles from comment #4)
> Also, while the HIG should be followed, I'm doubtful that we should (or do
> anywhere else) enforce its guidelines in default constructed widgets.
For instance, this would create hassle for developers who are not targeting GNOME and therefore are not beholden to the HIG, or any GNOME apps with atypical needs.