gtk4: Add convenience traits for binding template callbacks to classes

[jf2048]

Finishes out the last part of #77

The old way of Self::bind_template(klass) still works, this PR shouldn't break any existing code

[sdroege]

Seems good to me otherwise

[bilelmoussaoui]

Looks good to me, I was wondering if we could have some trait that is defined in glib that would roughly looks like this

pub trait ObjectSubclassImpl {
    fn class_init(klass: &mut Self::Class) {

    }

    fn instance_init(instance: &InitializingObject<Self>) {

    }
}

and modify the ObjectSubclass to always call the functions of ObjectSubclassImpl . We could then make the CompositeTemplate macro implements that trait and that would hopefully allow us to drop at least the klass.bind_template() / obj.init_template(), sadly I don't see how this could also work for the callback attribute macro

[jf2048]

IMO it's not a good idea to do that without having template specialization, there are too many other things to do in class_init, e.g. set_layout_manager_type, set_css_name, install_action, set_accessible_role, etc. The other option is to make a big macro and add support for all of that

[bilelmoussaoui]

IMO it's not a good idea to do that without having template specialization, there are too many other things to do in class_init, e.g. set_layout_manager_type, set_css_name, install_action, set_accessible_role, etc. The other option is to make a big macro and add support for all of that

What I meant is to have something like the subclassing code where you have a trait with the default implementations and a trait for modifying that default behaviour. In some cases you don't even need to chain-up (like the dispose in ObjectImpl because it is automatically done for you). So something along that could work I guess while still allowing you to override class_init and do whatever other things you need to do. Except the bind_template/init_template will no longer be necessary because they are the default implementations (that would be generated with the CompositeTemplate macro).

Note that is roughly an idea and it probably can't work for some technical reason I didn't thought of :)

[jf2048]

It can't work because subclasses always have to implement ObjectImpl even if it is empty in order to use the default impl. For any new trait we would add, every subclass would now also have to use

impl ObjectSubclassImpl for MyWidget {}

Or something like that, to use the default impl there

[bilelmoussaoui]

Indeed, completely forgot about that part. Maybe we could have some widget! macro in the future :)