After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 611004 - Make GtkFrame good for both design and accessibility
Make GtkFrame good for both design and accessibility
Product: gtk+
Classification: Platform
Component: Widget: Other
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Depends on:
Reported: 2010-02-24 20:48 UTC by Luca Ferretti
Modified: 2017-03-06 14:16 UTC
See Also:
GNOME target: ---
GNOME version: ---

Screenshot of GtkFrame in glade-3 with spurious 1 pixel border (12.12 KB, image/png)
2010-02-24 21:02 UTC, Luca Ferretti

Description Luca Ferretti 2010-02-24 20:48:10 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 [1])

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 :)

Comment 1 Luca Ferretti 2010-02-24 20:50:51 UTC
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...
Comment 2 Luca Ferretti 2010-02-24 21:02:26 UTC
Created attachment 154625 [details]
Screenshot of GtkFrame in glade-3 with spurious 1 pixel border
Comment 3 Christian Dywan 2010-02-25 09:45:42 UTC
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.
Comment 4 Daniel Boles 2017-03-06 14:14:55 UTC
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

If there is still any spurious padding anywhere, then a specific new bug could be opened.
Comment 5 Daniel Boles 2017-03-06 14:16:22 UTC
(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.