Support defining style class(es) in builder constructors about gtk3-rs

[sdroege]

Do you have a proposal how this should look like in the end, i.e. how code using it would ideally look like? The main problem here seems to be that it's not a direct property of the widget, but you need to get a reference to its style context and then add the class to that.

[mmstick]

I see two approaches:

In-Builder

Widget builders could inherit a trait that configures an internally-managed Option<StyleContextBuilder>. The builder could contain a SmallVec<[GString; 4]> for storing each class added.

let widget = WidgetBuilder::new()
    .add_class("class1");
    .add_class("class2")
    .build();

In-Widget-Builder

And/or widgets could provide a method with the following signature:

Fn(&self, mut func: FnMut(&StyleContext)) -> &Self

Which would allow it to be used like so, in combination with similar methods (ContainerExt::add).

widget
    .style_context(|ctx| {
        ctx.add_class("class1");
        ctx.add_class("class2");
    })
    .add(&widget1)
    .add(&widget2)

[sdroege]

The problem with directly adding it on the builder (option 1) is that it then moves methods of contained objects to the top-level object. Sooner or later that's going to cause problems with naming conflicts :)

The second option sounds reasonable to me. @antoyo ?

[antoyo]

I like that idea very much (actually, I thought of something similar for a relm rewrite).
However, I think it's out of scope of the builders though: they were meant to add type safety for constructing objects, not to go declarative everywhere (even though I would like that).
So, I think it should be outside gtk-rs.
One idea I had was to create and implement traits on the builders themselves to add such kind of feature.
That trait would need its own build() method that would call the original builder's build() method.
I think this would work, but I did not test that idea.

@sdroege:
please tell me if I'm wrong: that's my own conception of the builders, but maybe we want to go declarative or something (I'd like that, actually).

[sdroege]

I think you're right and this seems to go too far away from plain bindings to a higher-level API. The builders as they are seem acceptable as they only expose the concept of construct-only properties that already exists in GObject. Making them more generic to also allow for arbitrary other "construction operations" seems to be too much for bindings.

[GuillaumeGomez]

I guess it can be closed then?

[bilelmoussaoui]

GTK4 has a add_css_class, remove_css_class, set_css_classes & has_css_class at Widget level and I don't think as well that the bindings should offer more than the bindings themselves