ruby-gnome2-devel-en

[ruby-gnome2-devel-en] How-To Interfaces

[Thomas M. <ku...@ro...>]

Hello,

first of all, thanks for your great projekt. Really useful for ruby 
programms!

Now to my problem: I'm trying to implement an interface but I'm always 
getting the following error:

peas-ruby.rb:45:in `append_features': Not a subclass of
GLib::Instantiatable (TypeError)
       from peas-ruby.rb:46:in 'include'
       from peas-ruby.rb:46:in '<class:TestPlugin>'
       from peas-ruby.rb:41:in '<main>'


The code looks like this:

class TestPlugin < GLib::Object # GLib::Instantiatable doesn't work too

   include Peas::Activtabable # Peas::Activatable.class => Module

   def activate()

   end

   […]

end

Doing a TestPlugin.ancestors reveals that GLib::Instantiatable is 
actually in the class hierarchy.

Am I doing interface implementation wrong here? Is it even supported by 
ruby-gnome2?

Btw, I'm using GObjectIntrospection::Loader to load libpeas bindings 
through Peas-1.0.typelib. This part seems to work okay, but maybe I'm 
missing something here? Are there other interfaces that are known to 
work fine?

Best regards.

Re: [ruby-gnome2-devel-en] How-To Interfaces

[cedlemo <ce...@gm...>]

Hi Thomas, I don't really understand what you are calling an interface. 
Are you building a Peas ruby module
based on the GObjectInstrospection::Loader?

I don't understand why you try to create a subclass of GLib::Object 
directly.

If you could explain me this, I should be more helpful.

cedlemo

On 21/07/2016 18:33, Thomas Martitz wrote:
> Hello,
>
> first of all, thanks for your great projekt. Really useful for ruby
> programms!
>
> Now to my problem: I'm trying to implement an interface but I'm always
> getting the following error:
>
> peas-ruby.rb:45:in `append_features': Not a subclass of
> GLib::Instantiatable (TypeError)
>         from peas-ruby.rb:46:in 'include'
>         from peas-ruby.rb:46:in '<class:TestPlugin>'
>         from peas-ruby.rb:41:in '<main>'
>
>
> The code looks like this:
>
> class TestPlugin < GLib::Object # GLib::Instantiatable doesn't work too
>
>     include Peas::Activtabable # Peas::Activatable.class => Module
>
>     def activate()
>
>     end
>
>     […]
>
> end
>
> Doing a TestPlugin.ancestors reveals that GLib::Instantiatable is
> actually in the class hierarchy.
>
> Am I doing interface implementation wrong here? Is it even supported by
> ruby-gnome2?
>
> Btw, I'm using GObjectIntrospection::Loader to load libpeas bindings
> through Peas-1.0.typelib. This part seems to work okay, but maybe I'm
> missing something here? Are there other interfaces that are known to
> work fine?
>
> Best regards.
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports.http://sdm.link/zohodev2dev
> _______________________________________________
> ruby-gnome2-devel-en mailing list
> rub...@li...
> https://lists.sourceforge.net/lists/listinfo/ruby-gnome2-devel-en

Re: [ruby-gnome2-devel-en] How-To Interfaces

[Thomas M. <ku...@ro...>]

Am 21.07.2016 um 20:49 schrieb cedlemo:
> Hi Thomas, I don't really understand what you are calling an interface.
> Are you building a Peas ruby module
> based on the GObjectInstrospection::Loader?
>
> I don't understand why you try to create a subclass of GLib::Object
> directly.
>
> If you could explain me this, I should be more helpful.


PeasActivatable is a GObject interface, see [1] and [2]. I want to 
create a ruby class that implements this interface. Finally I want 
libpeas (a C library) to interact with instances of that class (have 
libpeas call activate, deactivate and update_state methods()).

In ruby, a module seems to correspond largely to an interface in GObject.

libpeas provides a typelib, therefore I use 
GObjectInstrospection::Loader to load the typelib and import libpeas 
bindings into Ruby space. This part seems to work fine, as I'm able to 
introspect most (if not all) of libpeas bindings.

In GObject, interfaces can have "prerequisite type", which means that 
implementations of the interface must also be a subclass of that class 
type. PeasActivatable specifies G_TYPE_OBJECT as the prerequisite. 
Therefore I want to subclass GLib::Object.

[1] 
https://developer.gnome.org/gobject/stable/gtype-non-instantiable-classed.html
[2] https://developer.gnome.org/libpeas/stable/PeasActivatable.html

Best regards

Re: [ruby-gnome2-devel-en] How-To Interfaces

[cedlemo <ce...@gm...>]

Thomas,

When you use the GObjectInstrospection::Loader, you don't need to 
subclass GLib::Object. Look at the vte3 loader :
https://github.com/ruby-gnome2/ruby-gnome2/blob/master/vte3/lib/vte3.rb 
which is really simple

then if you do

irb -r vte3
 >Vte::Terminal.ancestors

[Vte::Terminal, Gtk::Scrollable, Gtk::Widget, Gtk::Buildable, 
Atk::Implementor, GLib::Interface, GLib::InitiallyUnowned, GLib::Object, 
GLib::Instantiatable, Object, Kernel, BasicObject]

All the hierarchy of classes, sub-class, dependencies have been done.


I didn't know about the interfaces or if they are supported. I am sure 
that Kou will give you a better answer on this advanced topic.



cedlemo

On 21/07/2016 21:00, Thomas Martitz wrote:
> Am 21.07.2016 um 20:49 schrieb cedlemo:
>> Hi Thomas, I don't really understand what you are calling an interface.
>> Are you building a Peas ruby module
>> based on the GObjectInstrospection::Loader?
>>
>> I don't understand why you try to create a subclass of GLib::Object
>> directly.
>>
>> If you could explain me this, I should be more helpful.
>
> PeasActivatable is a GObject interface, see [1] and [2]. I want to
> create a ruby class that implements this interface. Finally I want
> libpeas (a C library) to interact with instances of that class (have
> libpeas call activate, deactivate and update_state methods()).
>
> In ruby, a module seems to correspond largely to an interface in GObject.
>
> libpeas provides a typelib, therefore I use
> GObjectInstrospection::Loader to load the typelib and import libpeas
> bindings into Ruby space. This part seems to work fine, as I'm able to
> introspect most (if not all) of libpeas bindings.
>
> In GObject, interfaces can have "prerequisite type", which means that
> implementations of the interface must also be a subclass of that class
> type. PeasActivatable specifies G_TYPE_OBJECT as the prerequisite.
> Therefore I want to subclass GLib::Object.
>
> [1]
> https://developer.gnome.org/gobject/stable/gtype-non-instantiable-classed.html
> [2] https://developer.gnome.org/libpeas/stable/PeasActivatable.html
>
> Best regards
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports.http://sdm.link/zohodev2dev
> _______________________________________________
> ruby-gnome2-devel-en mailing list
> rub...@li...
> https://lists.sourceforge.net/lists/listinfo/ruby-gnome2-devel-en

Re: [ruby-gnome2-devel-en] How-To Interfaces

[Thomas M. <ku...@ro...>]

Am 21.07.2016 um 21:48 schrieb cedlemo:
> All the hierarchy of classes, sub-class, dependencies have been done.

I can observe this for my Peas module (and its classes) as well. 
However, I'm taking about a custom class written Ruby (which shall 
implement an interface). Without explicit inheritance from GLib::Object 
it just inherits Ruby's Object.


>
> I didn't know about the interfaces or if they are supported. I am sure
> that Kou will give you a better answer on this advanced topic.

Thank you anyway. I'll patently wait for Kou or any other knowledgeable 
person then.

Best regards

Re: [ruby-gnome2-devel-en] How-To Interfaces

[Mario S. <ma...@ru...>]

Hello Thomas,

What your looking for to allow your Custom Ruby library to work with
libpeas, and various other things, that require the GTYPE, is the ability
to register it.  To do this, I utilize this method of creating the class
name:

module MyModule
  class MyCustomClass < GLib::Object
    unless defined? MYCUSTOMCLASS_TYPE
      MYCUSTOMCLASS_TYPE = self.name.split(":").collect {|x| x.empty? ? nil
: x}.compact.join("_")
      type_register(MYCUSTOMCLASS_TYPE)
    end

    # Proceed with defining my class, and required methods
  end
end

This class is a simple class, that inherits from GLib::Object, but can
inherit from anything, as long as somewhere in it's ancestry, GLib::Object
is a parent class for it.  What the above does is:

Converts MyModule::MyCustomClass to MyModule_MyCustomClass (Or
MYMODULE_MYCUSTOMCLASS in C terms), and then calls
GLib::Object#type_register() with the class name, which is defined by
MYCUSTOMCLASS_TYPE.  I include a defined? check, incase the file is loaded
/ required multiple times, or somehow re-loaded, the class doesn't
accidentally get re-registered with GLib.  Once you have done this, you
should be able to associate the MyModule::MyCustomClass::MYCUSTOMCLASS_TYPE
(Or just TYPE for short), with libpeas, and have libpeas utilize this.

Hope this helps you out.



Mario Steele
Ruby Developer
C# Developer
Java Developer

On Thu, Jul 21, 2016 at 3:57 PM, Thomas Martitz <ku...@ro...> wrote:

> Am 21.07.2016 um 21:48 schrieb cedlemo:
> > All the hierarchy of classes, sub-class, dependencies have been done.
>
> I can observe this for my Peas module (and its classes) as well.
> However, I'm taking about a custom class written Ruby (which shall
> implement an interface). Without explicit inheritance from GLib::Object
> it just inherits Ruby's Object.
>
>
> >
> > I didn't know about the interfaces or if they are supported. I am sure
> > that Kou will give you a better answer on this advanced topic.
>
> Thank you anyway. I'll patently wait for Kou or any other knowledgeable
> person then.
>
> Best regards
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports.http://sdm.link/zohodev2dev
> _______________________________________________
> ruby-gnome2-devel-en mailing list
> rub...@li...
> https://lists.sourceforge.net/lists/listinfo/ruby-gnome2-devel-en
>

Re: [ruby-gnome2-devel-en] How-To Interfaces

[Thomas M. <ku...@ro...>]

Am 22.07.2016 um 04:13 schrieb Mario Steele:
> Hello Thomas,
>
> What your looking for to allow your Custom Ruby library to work with 
> libpeas, and various other things, that require the GTYPE, is the 
> ability to register it.  To do this, I utilize this method of creating 
> the class name:
>
> module MyModule
>   class MyCustomClass < GLib::Object
>     unless defined? MYCUSTOMCLASS_TYPE
>       MYCUSTOMCLASS_TYPE = self.name.split(":").collect {|x| x.empty? 
> ? nil : x}.compact.join("_")
> type_register(MYCUSTOMCLASS_TYPE)
>     end
>
>     # Proceed with defining my class, and required methods
>   end
> end
>
> This class is a simple class, that inherits from GLib::Object, but can 
> inherit from anything, as long as somewhere in it's ancestry, 
> GLib::Object is a parent class for it.  What the above does is:
>
> Converts MyModule::MyCustomClass to MyModule_MyCustomClass (Or 
> MYMODULE_MYCUSTOMCLASS in C terms), and then calls 
> GLib::Object#type_register() with the class name, which is defined by 
> MYCUSTOMCLASS_TYPE.  I include a defined? check, incase the file is 
> loaded / required multiple times, or somehow re-loaded, the class 
> doesn't accidentally get re-registered with GLib.  Once you have done 
> this, you should be able to associate the 
> MyModule::MyCustomClass::MYCUSTOMCLASS_TYPE (Or just TYPE for short), 
> with libpeas, and have libpeas utilize this.
>
> Hope this helps you out.


Thanks, this helped a bit. Based on your suggestion I found in the 
examples that I should do:

class Foo < GLib::Object
   type_register # this was missing
   […]
end

I can now successfully create a global $foo = Foo.new and in C:

void *(*rbg2gobj)(VALUE obj);
foo = rb_gv_get("$foo");
rbg2gobj = dlsym(NULL, "rbgobj_instance_from_ruby_object");
foo_gobj = rbg2gobj(foo);
assert(G_IS_OBJECT(foo_gobj));

However, I'm still unable to implement the Peas::Activatable interface, 
due to the error message.

When I remove the specific check that throws this from the ruby-gnome2 
code, then I can use the "include Peas::Activatable" statement. Then, 
$foo.is_a?(Peas::Activatable) even returns true. BUT the following fails 
(in C):

assert(PEAS_IS_ACTIVATABLE(foo_gobj));

Doing the "include Peas::Activatable" before or after the type_register 
call doesn't seem to matter.

Best regards

Re: [ruby-gnome2-devel-en] How-To Interfaces

[Mario S. <ma...@ru...>]

Here's a silly question,

Have you tried to implement the methods Peas::Activatable requires? EG:
activate, deactivate, update_state, even if the methods aren't actually
doing anything?

EG:

class Foo < GLib::Object
   type_register

   include Peas::Activatable

   def activate
     puts "Activate is here!"
   end

   def deactivate
     puts "Deactivate is here!"
   end

   def update_state
     puts "Update State is here!"
   end
end

$foo = Foo.new

Then try on your C side: assert(PEAS_IS_ACTIVATABLE(foo_gobj))


Mario Steele
Ruby Developer
C# Developer
Java Developer

On Fri, Jul 22, 2016 at 2:07 AM, Thomas Martitz <ku...@ro...> wrote:

> Am 22.07.2016 um 04:13 schrieb Mario Steele:
> > Hello Thomas,
> >
> > What your looking for to allow your Custom Ruby library to work with
> > libpeas, and various other things, that require the GTYPE, is the
> > ability to register it.  To do this, I utilize this method of creating
> > the class name:
> >
> > module MyModule
> >   class MyCustomClass < GLib::Object
> >     unless defined? MYCUSTOMCLASS_TYPE
> >       MYCUSTOMCLASS_TYPE = self.name.split(":").collect {|x| x.empty?
> > ? nil : x}.compact.join("_")
> > type_register(MYCUSTOMCLASS_TYPE)
> >     end
> >
> >     # Proceed with defining my class, and required methods
> >   end
> > end
> >
> > This class is a simple class, that inherits from GLib::Object, but can
> > inherit from anything, as long as somewhere in it's ancestry,
> > GLib::Object is a parent class for it.  What the above does is:
> >
> > Converts MyModule::MyCustomClass to MyModule_MyCustomClass (Or
> > MYMODULE_MYCUSTOMCLASS in C terms), and then calls
> > GLib::Object#type_register() with the class name, which is defined by
> > MYCUSTOMCLASS_TYPE.  I include a defined? check, incase the file is
> > loaded / required multiple times, or somehow re-loaded, the class
> > doesn't accidentally get re-registered with GLib.  Once you have done
> > this, you should be able to associate the
> > MyModule::MyCustomClass::MYCUSTOMCLASS_TYPE (Or just TYPE for short),
> > with libpeas, and have libpeas utilize this.
> >
> > Hope this helps you out.
>
>
> Thanks, this helped a bit. Based on your suggestion I found in the
> examples that I should do:
>
> class Foo < GLib::Object
>    type_register # this was missing
>    […]
> end
>
> I can now successfully create a global $foo = Foo.new and in C:
>
> void *(*rbg2gobj)(VALUE obj);
> foo = rb_gv_get("$foo");
> rbg2gobj = dlsym(NULL, "rbgobj_instance_from_ruby_object");
> foo_gobj = rbg2gobj(foo);
> assert(G_IS_OBJECT(foo_gobj));
>
> However, I'm still unable to implement the Peas::Activatable interface,
> due to the error message.
>
> When I remove the specific check that throws this from the ruby-gnome2
> code, then I can use the "include Peas::Activatable" statement. Then,
> $foo.is_a?(Peas::Activatable) even returns true. BUT the following fails
> (in C):
>
> assert(PEAS_IS_ACTIVATABLE(foo_gobj));
>
> Doing the "include Peas::Activatable" before or after the type_register
> call doesn't seem to matter.
>
> Best regards
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports.http://sdm.link/zohodev2dev
> _______________________________________________
> ruby-gnome2-devel-en mailing list
> rub...@li...
> https://lists.sourceforge.net/lists/listinfo/ruby-gnome2-devel-en
>

Re: [ruby-gnome2-devel-en] How-To Interfaces

[Thomas M. <ku...@ro...>]

Am 22.07.2016 um 10:28 schrieb Mario Steele:
> Here's a silly question,
>

Hello,

not silly at all!

> Have you tried to implement the methods Peas::Activatable requires? 
> EG: activate, deactivate, update_state, even if the methods aren't 
> actually doing anything?
>
> EG:
>
> class Foo < GLib::Object
>    type_register
>
>    include Peas::Activatable
>
>    def activate
>      puts "Activate is here!"
>    end
>
>    def deactivate
>      puts "Deactivate is here!"
>    end
>
>    def update_state
>      puts "Update State is here!"
>    end
> end
>
> $foo = Foo.new
>
> Then try on your C side: assert(PEAS_IS_ACTIVATABLE(foo_gobj))

Yes, I have tried this, without success.

At this point I'm wondering if implementing GObject interfaces is 
supported at all? Surprising if not, since interfaces are a fundamental 
aspect of the GObject system (and OOP in general).

Best regards.

Re: [ruby-gnome2-devel-en] How-To Interfaces

[Mario S. <ma...@ru...>]

You know, thinking about it, it may not be, as the methods defined on the
ruby object isn't directly available on the c side, without having to get a
pointer to the ruby method and called via a ruby specific c routine.  If
you can figure out how to capture and call the specific ruby method from
the c side to the ruby side you should be good.

On Jul 22, 2016 4:33 AM, "Thomas Martitz" <ku...@ro...> wrote:

> Am 22.07.2016 um 10:28 schrieb Mario Steele:
> > Here's a silly question,
> >
>
> Hello,
>
> not silly at all!
>
> > Have you tried to implement the methods Peas::Activatable requires?
> > EG: activate, deactivate, update_state, even if the methods aren't
> > actually doing anything?
> >
> > EG:
> >
> > class Foo < GLib::Object
> >    type_register
> >
> >    include Peas::Activatable
> >
> >    def activate
> >      puts "Activate is here!"
> >    end
> >
> >    def deactivate
> >      puts "Deactivate is here!"
> >    end
> >
> >    def update_state
> >      puts "Update State is here!"
> >    end
> > end
> >
> > $foo = Foo.new
> >
> > Then try on your C side: assert(PEAS_IS_ACTIVATABLE(foo_gobj))
>
> Yes, I have tried this, without success.
>
> At this point I'm wondering if implementing GObject interfaces is
> supported at all? Surprising if not, since interfaces are a fundamental
> aspect of the GObject system (and OOP in general).
>
> Best regards.
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports.http://sdm.link/zohodev2dev
> _______________________________________________
> ruby-gnome2-devel-en mailing list
> rub...@li...
> https://lists.sourceforge.net/lists/listinfo/ruby-gnome2-devel-en
>

Re: [ruby-gnome2-devel-en] How-To Interfaces

[Thomas M. <ku...@ro...>]

Hello,

I have determined (by going through the code) that ruby-gnome2 simply 
doesn't support GObject interfaces at the moment.

I'm currently working on adding such support which seems not too hard 
given the truly fine codebase. However, it's a bit complicated by the 
fact that interfaces can also require properties. Implementations of an 
interface have to override properties by calling 
g_object_class_override_property() in their class_init.

Properties are currently handled by calling "install_property" after 
"type_register". This conflicts with the above so I need to find a way 
to make interface&properties work.

Best regards

Re: [ruby-gnome2-devel-en] How-To Interfaces

[Kouhei S. <ko...@co...>]

Hi,

In <579...@ro...>
  "[ruby-gnome2-devel-en] How-To Interfaces" on Thu, 21 Jul 2016 18:33:34 +0200,
  Thomas Martitz <ku...@ro...> wrote:

> The code looks like this:
> 
> class TestPlugin < GLib::Object # GLib::Instantiatable doesn't work too
> 
>    include Peas::Activtabable # Peas::Activatable.class => Module
> 
>    def activate()
> 
>    end
> 
>    […]
> 
> end
> 
> Doing a TestPlugin.ancestors reveals that GLib::Instantiatable is 
> actually in the class hierarchy.
> 
> Am I doing interface implementation wrong here? Is it even supported by 
> ruby-gnome2?

Ruby-GNOME2 doesn't support implementing interface in
Ruby. Because it needs interface specific C code.

> Btw, I'm using GObjectIntrospection::Loader to load libpeas bindings 
> through Peas-1.0.typelib. This part seems to work okay, but maybe I'm 
> missing something here? Are there other interfaces that are known to 
> work fine?

I think that you should implement Ruby loader for libpeas
instead of implementing libpeas bindings.

It means that
https://git.gnome.org/browse/libpeas/tree/loaders/ruby is implemented at
https://git.gnome.org/browse/libpeas/tree/loaders like
https://git.gnome.org/browse/libpeas/tree/loaders/python .


Thanks,
--
kou

Re: [ruby-gnome2-devel-en] How-To Interfaces

[Thomas M. <ku...@ro...>]

Am 23. Juli 2016 16:35:45 MESZ, schrieb Kouhei Sutou <ko...@co...>:
>Hi,
>

>
>Ruby-GNOME2 doesn't support implementing interface in
>Ruby. Because it needs interface specific C code.
>

What do you mean with interface specific c code? From my current observations it should be possible to extend rbg (seems to be the general shorthand for ruby-gnome2 in the code so I'll use that) such that you can create classes (inheriting gobject) that implement gobject interfaces purely in ruby.

pygobject can do it after all.

>> Btw, I'm using GObjectIntrospection::Loader to load libpeas bindings 
>> through Peas-1.0.typelib. This part seems to work okay, but maybe I'm
>
>> missing something here? Are there other interfaces that are known to 
>> work fine?
>
>I think that you should implement Ruby loader for libpeas
>instead of implementing libpeas bindings.
>
>It means that
>https://git.gnome.org/browse/libpeas/tree/loaders/ruby is implemented
>at
>https://git.gnome.org/browse/libpeas/tree/loaders like
>https://git.gnome.org/browse/libpeas/tree/loaders/python .
>
>
>Thanks,
>--
>kou


That's clear. Before I implement a loader I need rbg to meet the requirements for libpeas. That's mainly supporting interfaces. The libpeas loader would look for ruby classes that implement certain interfaces, and instantiate them.

Actually libpeas bindings seem to work mostly out of the box based on introspection. For example, rgb already generates a module for the PeasActivatable interface.

PS: I'm currently having a problem with "rgbobjects" being initialized twice if I call g_type_interface_static() for it

Best regards 

Re: [ruby-gnome2-devel-en] How-To Interfaces

[Thomas M. <ku...@ro...>]

Am 24.07.2016 um 05:00 schrieb Kouhei Sutou:
> Hi,
>
> In <453...@ro...>
>    "Re: [ruby-gnome2-devel-en] How-To Interfaces" on Sat, 23 Jul 2016 17:16:33 +0200,
>    Thomas Martitz <ku...@ro...> wrote:
>
>>> Ruby-GNOME2 doesn't support implementing interface in
>>> Ruby. Because it needs interface specific C code.
>>>
>> What do you mean with interface specific c code? From my
>> current observations it should be possible to extend rbg
>> (seems to be the general shorthand for ruby-gnome2 in the
>> code so I'll use that) such that you can create classes
>> (inheriting gobject) that implement gobject interfaces
>> purely in ruby.
> Do you know how to implement GObject interface in C?
>
> Here are codes that GtkSizeGroup implements GtkBuildable:
>
>    https://git.gnome.org/browse/gtk+/tree/gtk/gtksizegroup.c#n150
>    https://git.gnome.org/browse/gtk+/tree/gtk/gtksizegroup.c#n273
>
> You need to assign pointers of GObject interface functions
> like:
>
>    iface->custom_tag_start = gtk_size_group_buildable_custom_tag_start;
>    iface->custom_finished = gtk_size_group_buildable_custom_finished;
>
> https://git.gnome.org/browse/gtk+/tree/gtk/gtksizegroup.c#n276
>
> The function type is GObject interface specific. So we need
> to create function for each GObject interface functions.
>
> How did you implement GObject interfaces purely in Ruby?


I see what you mean. Actually libffi provides that ability. You can use 
ffi closures to dynamically create trampoline (trampoline == closure) 
functions which call a generic ffi callback. The ffi callback is passed 
enough information to resolve which interface method to call (how the 
ffi callback receives the parameters from the trampoline is managed by 
libffi). The ffi callback also receives the paramters that the 
trampoline in order to link the method call to the actual GObjecet instance.

The gobject-introspection library even has a helper function for that: 
g_callable_info_prepare_closure(). This receives a GICallableInfo and 
creates such a trampoline function. You also pass it an ffi callback 
which would (in our case) dispatch the method call into Ruby space 
(using rb_funcall or whatever).

I have prototyped what I mentioned above, see 
http://pastebin.geany.org/A26m9/. The printfs eventually print "closure 
for TestPlugin::activate called" for a my test ruby class which includes 
the Peas::Activatable module.

rbg uses libffi already in another place, and it comes automatically via 
glib dependency.

>
>> pygobject can do it after all.
> Could you show us how PyGObject do it?

pygobject does what I described above, it starts here: 
https://git.gnome.org/browse/pygobject/tree/gi/gimodule.c#n459
_pygi_make_native_closure() makes g_callable_info_prepare_closure() call 
based on GI information and then sets the function pointer to that 
trampoline function (*method_ptr = closure->closure)

>
>> That's clear. Before I implement a loader I need rbg to
>> meet the requirements for libpeas. That's mainly
>> supporting interfaces. The libpeas loader would look for
>> ruby classes that implement certain interfaces, and
>> instantiate them.
> You can use Ruby-GNOME2 when you implement the Ruby loader.

That's my plan.

>
>> PS: I'm currently having a problem with "rgbobjects" being
>> initialized twice if I call g_type_interface_static() for
>> it
> g_type_register_static()?
> I don't know about the details of what you're doing but you
> should not call XXX_static() dynamically.

I believe the _dynamic functions are meant to be used with GTypePlugins. 
I don't think rbg uses this mechanism 
(GLib::Object.type_register/rbgobj_register_type uses 
g_type_register_static). pygobject doesn't do either and also uses 
_static variants.

You can use the static variants if you don't plan to recycle GType 
values IIUC.

Best regards.

Re: [ruby-gnome2-devel-en] How-To Interfaces

[Kouhei S. <ko...@co...>]

Hi,

In <60a...@ro...>
  "Re: [ruby-gnome2-devel-en] How-To Interfaces" on Sun, 24 Jul 2016 12:24:46 +0200,
  Thomas Martitz <ku...@ro...> wrote:

> I have prototyped what I mentioned above, see 
> http://pastebin.geany.org/A26m9/. The printfs eventually print "closure 
> for TestPlugin::activate called" for a my test ruby class which includes 
> the Peas::Activatable module.

Thanks.

We can't use this approach because glib2 gem doesn't depend
on GObject Introspection.

It's OK that we add a singleton method to
GObjectIntrospection::Loader for the feature.

> I believe the _dynamic functions are meant to be used with GTypePlugins. 
> I don't think rbg uses this mechanism 
> (GLib::Object.type_register/rbgobj_register_type uses 
> g_type_register_static). pygobject doesn't do either and also uses 
> _static variants.
> 
> You can use the static variants if you don't plan to recycle GType 
> values IIUC.

Sorry.
Maybe you're right.


Thanks,
--
kou

Re: [ruby-gnome2-devel-en] How-To Interfaces

[Kouhei S. <ko...@co...>]

Hi,

In <453...@ro...>
  "Re: [ruby-gnome2-devel-en] How-To Interfaces" on Sat, 23 Jul 2016 17:16:33 +0200,
  Thomas Martitz <ku...@ro...> wrote:

>>Ruby-GNOME2 doesn't support implementing interface in
>>Ruby. Because it needs interface specific C code.
>>
> 
> What do you mean with interface specific c code? From my
> current observations it should be possible to extend rbg
> (seems to be the general shorthand for ruby-gnome2 in the
> code so I'll use that) such that you can create classes
> (inheriting gobject) that implement gobject interfaces
> purely in ruby.

Do you know how to implement GObject interface in C?

Here are codes that GtkSizeGroup implements GtkBuildable:

  https://git.gnome.org/browse/gtk+/tree/gtk/gtksizegroup.c#n150
  https://git.gnome.org/browse/gtk+/tree/gtk/gtksizegroup.c#n273

You need to assign pointers of GObject interface functions
like:

  iface->custom_tag_start = gtk_size_group_buildable_custom_tag_start;
  iface->custom_finished = gtk_size_group_buildable_custom_finished;

https://git.gnome.org/browse/gtk+/tree/gtk/gtksizegroup.c#n276

The function type is GObject interface specific. So we need
to create function for each GObject interface functions.

How did you implement GObject interfaces purely in Ruby?

> pygobject can do it after all.

Could you show us how PyGObject do it?

> That's clear. Before I implement a loader I need rbg to
> meet the requirements for libpeas. That's mainly
> supporting interfaces. The libpeas loader would look for
> ruby classes that implement certain interfaces, and
> instantiate them.

You can use Ruby-GNOME2 when you implement the Ruby loader.

> PS: I'm currently having a problem with "rgbobjects" being
> initialized twice if I call g_type_interface_static() for
> it

g_type_register_static()?
I don't know about the details of what you're doing but you
should not call XXX_static() dynamically.


Thanks,
--
kou