Re: Started adding GObject signals to gnome-class

[Federico Mena Quintero <federico gnome org>]

On Thu, 2017-08-31 at 20:11 +0300, Sebastian Dröge wrote:
> You can find the oven here:
>   https://github.com/sdroege/gobject-example-rs

Mmmm, nice and warm.

Holy shit, this is going to be really, really useful.  I'm going to
have a lot of fun next week basically cutting&pasting from your module
into gnome-class's code generator :)

> I'm not very happy with the code organization yet, any suggestions
> let
> me know :) It's all feeling mashed together, the actual safe
> implementations of the stuff are mixed with the boilerplate.

Although I haven't read through the code in detail, it's comforting
that the structure is very familiar from a C GObject perspective.

I do like how Niko added some "paranoid" features in gnome-class, to do
things like making some structs uninstantiable if they are
implementation details (e.g. you couldn't create a FooPrivate on your
own; you have to get it from the get_private() method).  Fortunately
this is just boilerplate in the code generator, and can be easily added
to your code.

> - 2 GObjects. Bar inherits from Foo. src/{foo,bar} contains the

This is very helpful.  Just last week I started learning how glib-rs
works, and this - how to inherit GObjects in Rust - is very nice to
have as a reference.

> - Signal "incremented" on Foo
> - Normal "number" GObject property on Bar

I see you have a Vec<signal_ids> inside the class private, indexed by
an enum.  What I was putting in gnome-class was "invisible" fields in
the class struct, sort of like FooClass.clicked_signal_id: u32.  They
would just take up space in the class struct; the corresponding C
headers would just have "dummy" fields for them.

The Rust code won't have to deal with signal ids, anyway, since all the
 emit_foo_signal() methods are auto-generated, anyway... but for the
implementation that the code generator emits, do you see any advantages
of one scheme over the other?

> - Makefile that builds all this, plus GObject-Introspection stuff
> - Python and Javascript example that uses it (can be run from the

This is *excellent* as a test harness :)

> Things to come:
> - Some GObject interface

Yes, please!  I'm thinking that right now we have

gobject_gen! {
    class Foo: Parent {
        ...
    }
}

should we also allow "interface" as well as "class" in there?

gobject_gen! {
    interface BarIface {
        fn oink(&self, ...) -> i32;
        fn moo(&self, ...);
    }
}

(Uh, can one derive a GTypeInterface from another one, sort of like
dependent traits?  I don't see it done anywhere in GTK+...)

> - Action signal

I looked briefly through the gobject source code and I *think* these
are just a flag?  There's no other distinction from normal signals,
apart from the convention of allowing them to be emitted from outside
the object's implementation...

> - Refcounted and copying boxed type

Being able to declare our own, public, #[repr(C)] boxed types would be
awesome.  And simple enums.

(Are GTypeModules too exotic to be worth considering right now?)

> Once it's all done, I was also going to blog about it. I think once
> the
> macro can generate all the boilerplate for these things, using
> GObject
> from Rust would be a good way of generating/exporting an expressive C
> API (that can do more things than plain C: inheritance, signals,
> properties, etc.) and automatically get bindings for arbitrary
> languages.

Yes!  This is the idea!

Thanks for your work on all of this; having working example code is
very very useful :)

  Federico