GNOME.org
 

Re: Started adding GObject signals to gnome-class

On 23 August 2017 02:52:00 EEST, Alberto Ruiz <aruiz gnome org> wrote:

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


Hi,

I think for the gnome-class stuff you should start using the glib-rs infrastructure for mapping all the 
types. And possibly also for inheritance expression.

There doesn't seem to be any conflict, just duplication if you do it again another time ;)


This is good timing BTW, I was going to write a full example of GObject subclasses with interfaces 
implementations, signals, action signals, properties, virtual methods, gobject-introspection support next 
week. Using the glib-rs infrastructure but otherwise manual. Goal would be to have a baseline / template to 
what gnome-class should be able to generate, to have it all written out and functional so that also someone 
not knowing the implementation details of GObject can start working on that.

That would then also show how the two things go well together, glib-rs and a GObject subclass implementation 
in Rust.

I'll get to this next week in any case, I have it all written out in my head.


For emitting signals, connecting to signals, property setting etc in a generic way via GValues, also see 
glib-rs and specifically the ObjectExt trait. I added all that there already, wrapped in a safe API, for the 
GStreamer bindings. Together with the GValue translation traits that makes it quite easy to use. I also have 
an example for the usage of that 
here:https://github.com/sdroege/gstreamer-rs/blob/master/examples/src/bin/playbin.rs


Sebastian
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]