Add additional type bounds to Impl traits

[felinira]

Mirrors gtk-rs/gtk-rs-core#1519
See gtk-rs/gtk-rs-core#1515

Open questions:

• GInitiallyUnowned: Technically a parent class, but we mostly ignore it in other places already
• Interfaces, especially the ones implemented by GtkWidget are currently not covered by the implementing classes. Should they? One normally doesn't need to reimplement them, but we need to check whether we are required to specify them for safety reasons anyway

[sdroege]

* [ ]  `GInitiallyUnowned`: Technically a parent class, but we mostly ignore it in other places already

I would ignore it here. It doesn't have its own impl trait, its own API, or anything. It's just a strange marker class :)

* [ ]  Interfaces, especially the ones implemented by `GtkWidget` are currently not covered by the implementing classes. Should they? One normally doesn't need to reimplement them, but we need to check whether we are required to specify them for safety reasons anyway

What do you mean, can you give a concrete example?

[felinira]

What do you mean, can you give a concrete example?

Right now we don't ensure that people add @implements gtk::Accessible, gtk::Buildable, gtk::ConstraintTarget for their widget subclasses.

We will now start requiring everyone to start adding all their parent classes here via @extends. But should we also require those interfaces to be specified as well? As in, add additional constraints to WidgetImpl to include IsA<Accessible>, IsA<Buildable> and IsA<ConstraintTarget>.

Or is this superfluous? I can see this being advantageous in the sense that the wrapper macro always forces you to add all required interfaces, and just following compiler errors will lead to a correct and exhaustive implementation. However it would also add additional burden, as you'd need to specify those three bounds everywhere even though Widget should basically imply them.

[bilelmoussaoui]

We will now start requiring everyone to start adding all their parent classes here via @extends. But should we also require those interfaces to be specified as well? As in, add additional constraints to WidgetImpl to include IsA, IsA and IsA.

I think that is the conceptually correct thing to do but it will make every app developer's life more miserable given our poor subclassing code infrastructure.

On the other hand, enforcing things to be correctly handled would mean an easier path forward for some more automation using macros.

So for my side, I will just take the risk and do that. Could you give it a try in a separate commit to see the impact?

[sdroege]

I think requiring this is more correct and we should enforce it.

[sdroege]

@felinira This also requires some additional change in gtk-rs-core or not? If so, we can also do it in a separate PR if you prefer

[bilelmoussaoui]

@felinira This also requires some additional change in gtk-rs-core or not? If so, we can also do it in a separate PR if you prefer

This cannot affect gtk-rs-core, there is no base object that implements some interfaces and have various sub-types. Maybe gstreamer-rs though :)

[sdroege]

Ah I thought one of the GIO interfaces maybe :)

[felinira]

Could you give it a try in a separate commit to see the impact?

Sure, will do that later this week

[sdroege]

Let's get this in then and do the interfaces separately or what do you think?

[bilelmoussaoui]

Sure

[bilelmoussaoui]

Thanks @felinira