GNOME Bugzilla – Bug 778771
GtkFrame: Automatically add a CSS class to identify the label widget
Last modified: 2018-05-02 18:06:15 UTC
At present, if e.g. I want to put a margin around the added child of a Frame, without affecting the "label widget", it seems I must manually add a .label class to the label widget and select against that, e.g. > frame > :not(border):not(.label) { /* blah */ } However, this will not work for the standard GtkLabel child created by the convenience function gtk_frame_set_label(char const*), and anyway, having to add the class to any custom widgets is pretty tedious. So I think it might be nice if whenever a widget was added using gtk_frame_set_label_widget(), it automatically got a style node named "framelabel" or something, enabling users to natively select on/against the label widget, avoiding the problems/work outlined above. Is this considered a good use of CSS nodes? If so, I can look into it.
Hm, the following currently works (for both set_label and set_label_widget) and is a lot more tolerable than my previous attempts at selectors for this: frame > :nth-child(2) I'm currently testing in GTK+ 3. Presumably in GTK+ 4, where there is no longer a border node, the selector would be :first-child. But this seems a bit obscure, so there might still be value in a named node for this purpose.
Thinking of the label-widget vs the 'main widget', I arrived at a more general question: whether there could be a CSS node or class to identify the 'main child' (set by gtk_container_add) of containers like GtkFrame, GtkWindow, etc. Such widgets' other, internal children seem to have a lot of potential to complicate CSS selection. An example of this comes from my experience of replacing Container::border-width with a margin or padding on the child. For example, to apply 12px of margin around any Window's child (assuming we don't want to specifically add any class to each such child to apply this), we then have to use something like this: window > :not(decoration):not(headerbar) It would be nicer to simple be able to do something like: window > main-child Of course, if any multi-child containers have internal widgets(?), that would need to be a class, not a node. (In reply to Daniel Boles from comment #1) > Hm, the following currently works (for both set_label and set_label_widget) > and is a lot more tolerable than my previous attempts at selectors for this: > > frame > :nth-child(2) I'm pretty sure I found this isn't reliable, as depending on whether the label-widget is added by the user, the index of the label-widget and the main child seem to get swapped around. I found that I needed to go back to the pair of /* label-widget */ frame > label, frame > .label /* added child */ frame > :not(label):not(.label):not(border) when again, these would be much nicer: frame > label-widget frame > main-child But I'm just starting to explore the relevant code for gadgets and suchlike, so there might be some reason this can't be done.
this can't be a node, for obvious reasons (that would lose the node name of the label/child widget)
Created attachment 351828 [details] [review] Frame: Give :label-widget CSS class .label-widget This will make it easier to style widgets added as the :label-widget
Of course, for master, this assumes that the label-widget is kept at all; see https://bugzilla.gnome.org/show_bug.cgi?id=779653#c28 I also assumed that reusing GTK_STYLE_CLASS_LABEL wasn't appropriate, hence creating a new one, but maybe I'm wrong; I'm not aware of the use cases for the various style classes with the same names as widget nodes.
> (In reply to Daniel Boles from comment #1) > > Hm, the following currently works (for both set_label and set_label_widget) > > and is a lot more tolerable than my previous attempts at selectors for this: > > > > frame > :nth-child(2) > > I'm pretty sure I found this isn't reliable, as depending on whether the > label-widget is added by the user, the index of the label-widget and the > main child seem to get swapped around. I've seen a few commits lately that were intended to ensure the ordering of internal children. Presumably the above sporadic behaviour is unintentional; would a patch to enforce the node ordering be accepted for 3.22? It seems unlikely that anyone was relying on the arbitrary ordering we seem to have at present. (And I guess they are marginally more probable, though still unlikely, to be already using any style class I might dream up for some other purpose.)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/759.