Re: GtkFrame has no frame border drawn?

[Richard Shann <richard rshann plus com>]

On Mon, 2015-08-10 at 15:05 +0100, Emmanuele Bassi wrote:
> Hi;
>
> On 10 August 2015 at 14:51, Richard Shann <richard rshann plus com> wrote:
>
> > Having invested effort in this it is exasperating to discover that GTK+
> > chooses a default theme that cripples one of the widgets - by failing to
> > draw a frame around the contents the user can no longer see clearly what
> > is being grouped by the frame.
>
> "Crippling" is a strong word, and one that I don't think applies.

I'm sorry if the word "cripples" seemed strong to you, I intended it in
a purely technical sense of "removes a major part of the functionality".
Since the widget in question only has one non-optional feature: "The
frame widget is a Bin that surrounds its child with a decorative frame
and an optional label", it is clearly the major part of the
functionality.  I can't think of another English word for this meaning
(vitiated? emasculated? these are not so common/have bad connotations).

> Grouping can be achieved by white space, for instance. Or by changing
> the background color. Or by changing the typographical appearance.

Thank you for these excellent suggestions. I tried 

gtk_widget_override_background_color (frame, GTK_STATE_FLAG_NORMAL, &color);

but could not see the effect (even adding padding or applying it to the
child GtkBox of the frame). I did however get colored labels by using
gtk_widget_override_color(), but then I read that these calls are
deprecated and that a lot more code would be required to do this
involving setting up styles.

> Just because you expect a border,

Well, I didn't expect a border until I read the documentation:
"The frame widget is a Bin that surrounds its child with a decorative
frame and an optional label."
then I expected a decorative frame surrounding the widget. I guess that
a theme could make all widgets invisible if it chose to set the
foreground color equal to the background color, but I don't expect theme
designers to do that or anything else that essentially negates the
documented behavior.

>  it does not mean your expectations
> are correct or are the only possible outcome.
>
> For instance, using a border around a GtkFrame has been deprecated in
> the GNOME HIG since the 2.x era, almost a decade ago:
> https://developer.gnome.org/hig-book/2.32/hig-book.html#controls-frames
>
> The human interface guidelines for MacOS also group controls without a
> border: 
> https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/ControlsView.html#//apple_ref/doc/uid/20000957-CH52-SW8
>
> In general, you want to use your GtkFrame with GTK_SHADOW_NONE,

then that should be the default and the Description should read

"The frame widget is a Bin that surrounds its child with a, (by default
invisible), decorative frame and an optional label."

>  and
> use spacing. The documentation of GtkShadowType also specifies that
> themes may very well not have different types of shadows, and you
> should not rely on them:
> https://developer.gnome.org/gtk3/stable/gtk3-Standard-Enumerations.html#GtkShadowType

a developer will only look up the documentation on the shadow type if
they have some reason not to use the default. So they won't see this
caveat, which after all would surely apply to most things - a theme
could be created to cripple almost any widget I would guess.

What would be nice would be to give GtkFrame the features suggested in
the GNOME HIG document you cited:

        gtk_frame_new_with_markup ()
        gtk_frame_set_indent ()

where the indent would behave nicely under re-sizing. Then the default
of GTK_SHADOW_NONE would make sense (else GtkFrame is almost a synonym
for GtkBin). Well, I hope that is a constructive suggestion,

best wishes

Richard Shann