Re: Started adding GObject signals to gnome-class

[Alberto Ruiz <aruiz gnome org>]

As per how to map G_TYPES, you should have a look at
https://github.com/gtk-rs/glib/blob/master/src/types.rs as most of the
work is done there. Specifically to the two last impls of the file.

I do foresee some clashing between the work we're doing with
gobject_gen and gtk-rs, eventually we'll need a roadmap to bring the
two things together and being able to subclass from existing C
GObjects and classes already bound by gtk-rs (say,
Gtk.Application...).

2017-08-22 2:22 GMT+01:00 Federico Mena Quintero <federico gnome org>:
> Dear rustaceans!
>
> Today I finally got off my ass and started adding GObject signals to
> gnome-class.  You can see my progress here:
>
> https://github.com/federicomenaquintero/gnome-class
>
> So far I'm just getting familiar with the way gnome-class is
> constructed.  I'm able to parse stuff like
>
>   gobject_gen! {
>       class Foo {
>           ...
>           signal clicked(&self);
>       }
>   }
>
> and generate a completely non-functional call to g_signal_newv() inside
> the generated class_init().
>
> I'm trying to define the appropriate syntax to declare signal flags;
> I'll probably base it on Vala, which uses something like this:
>
>     [Signal (action=true, detailed=true, run=true, no_recurse=true, no_hooks=true)]
>     public signal void sig_1 ();
>
> Some things which I don't know how to do yet:
>
> * Translate Rust types into G_TYPE_FOO equivalents, so that if there is
> something like
>
>      signal bar (x: c_uint, y: &str;) -> c_uint;
>
> we'll generate the appropriate
>
>      g_signal_newv(...
>                    G_TYPE_UINT, // return type
>                    2,           // n_params
>                    G_TYPE_UINT,
>                    G_TYPE_STRING);
>
> I'd like to constrain the Rust types that get accepted to those that
> are mappable to G_TYPE_*.  I have no idea how to say, "I can accept
> GObjects of superclass GFooClass" - i.e. where to get the appropriate
> GType value.  I also have no idea of how to declare new boxed types for
> GObject, e.g. if we wanted to export a plain struct for a
> GColor{r, g, b, a} or something similar.
>
> * How to remember the signal ids that g_signal_newv() generates, and
> how to emit the signals later.  Niko has a clever mechanism so that the
> generated code's internals use a number of traits and structs that are
> only accessible from there.  I'd probably want to generate something
> like
>
>   struct FooClassSignalIds {
>       foo_signal_id: c_uint,
>       bar_signal_id: c_uint,
>       ...
>   }
>
> and in class_init(), fill those out like
>
>   ids.foo_signal_id = g_signal_newv(...);
>   ids.bar_signal_id = g_signal_newv(...);
>
> Also, as a replacement for g_signal_emitv(), which is tricky to call by
> hand, maybe also have an
>
>   impl FooSignals for FooClass {
>       fn emit_foo(&self, x: c_uint, y: &str) -> c_uint {
>           g_signal_emitv(...);
>       }
>   }
>
> Then, the user's code would simply call
>
>   let r = self.emit_foo(42, "hello");
>
> or something.
>
> Does this seem sane?
>
> My main blocking point is how to translate Rust types into G_TYPE_* so
> I can call g_signal_newv() with the type declarations it needs.
>
> I'm also open to suggestions on how to store the signal ids and how to
> use them, although if that scheme of internal traits/structs works out,
> it seems like it would be nice to use.
>
>   Federico
> _______________________________________________
> Rust-list mailing list
> Rust-list gnome org
> https://mail.gnome.org/mailman/listinfo/rust-list



-- 
Cheers,
Alberto Ruiz