On Mon, 2015-08-10 at 15:05 +0100, Emmanuele Bassi wrote: > Hi; > > On 10 August 2015 at 14:51, Richard Shann <rich...@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 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list