Re: Started adding GObject signals to gnome-class
- From: Alberto Ruiz <aruiz gnome org>
- To: Federico Mena Quintero <federico gnome org>
- Cc: rust-list <rust-list gnome org>, Nicholas Matsakis <nmatsakis mozilla com>, Sebastian Dröge <sebastian centricular com>, Guillaume Gomez <guillaume1 gomez gmail com>, Brian Anderson <brson mozilla com>
- Subject: Re: Started adding GObject signals to gnome-class
- Date: Wed, 23 Aug 2017 00:52:00 +0100
This reminds me, pretty much nobody is subscribed to this list, adding
related parties to the discussion.
Please guys subscribe to this list!
2017-08-23 0:49 GMT+01:00 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
--
Cheers,
Alberto Ruiz
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]