Re: GtkFrame has no frame border drawn?

[Chris Vine <chris cvine freeserve co uk>]

On Mon, 10 Aug 2015 15:05:30 +0100
Emmanuele Bassi <ebassi gmail com> 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.
>
> Grouping can be achieved by white space, for instance. Or by changing
> the background color. Or by changing the typographical appearance.
>
> Just because you expect a border, 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, 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

Obviously everyone is entitled to their own opinion, but I just don't
agree with that.  For some grouping purposes you need a proper visual
representation which spacing does not offer, and the purpose of
GtkFrame is (or was) to provide it: if you want spacing there are other
ways to do it.  I found it intensely annoying with one particular
application which needed the correct visual representation.  To give the
Adwaita developer (or developers) credit, I convinced him/her/them
of this with respect to that application in a bug report and in
response they reinstated the "etched in" frame marking as a kind of
honourable compromise.

My suggestion that the documentation should make it clearer that
whether you get "A bin with a decorative frame and optional label" as
advertised was at the whim of the theme author, was not attended to.  No
one seemed willing to take ownership of the documentation and it
remains incorrect.

In my view essential components like frames should not be a matter of
theming.  But perhaps I am too averse to problem areas which encourage
people who like to think they know best about what is good for others
to assert themselves.

Chris