Re: [anjuta-devel] libpeas

[Sébastien Granjoux <seb sfo free fr>]

Hi,

Le 21/08/2010 12:56, Abderrahim KITOUNI a écrit :
> >   Then, even if libpeas calls functions using a more complex syntax, we can
> > still use it. Basically an Anjuta plugin is a shared library with only one
> ERROR: scripting languages cannot compile to shared libraries

Sure, but you don't need to create a shared library from python code. 
There are 2 things:

* The loader plugin that can be written in C, so it is shared library.

* The plugin itself written in another language, python by example. This 
doesn't need to be a shared library, it can be a script.


The loader plugin loads the plugin in whatever language it is. If it's a 
compiled language, it needs to load the shared library. If it's a 
script, it needs to load the corresponding interpreter and the script. 
Then, the register function is called, this function can be some 
compiled code or some python code run with the interpreter.


> You're missing the point : from your explanation above you want to use
> libpeas as a replacement for GModule, it's much more than that, it's
> intended as a full plugin system.

I have proposed to use libpeas as a replacement of GModule but it is 
only a minimal use. Writing such libpeas loader will allow us to load a 
plugin in all language supported by libpeas without writing any 
additional line in anjuta. But:

1. I think it's quite easy to write a loader for another language 
without using libpeas. It's not zero line of code but it's quite small.

2. Even if we use libpeas, we need to have complete bindings supporting 
advanced function of Glib (interface by example) which is not the case 
for all bindings at the moment.

I don't think such libpeas loader is really useful but I think it's 
possible.


> So instead of anjuta_glue_register_components it will be
> peas_register_types, and it is called automatically when loading the
> plugin. The problem is that it isn't easy to register types that
> correctly implement interfaces in all languages (e.g. it isn't
> possible in javascript now, I've made a patch for seed [1]).
>
> So, using libpeas means removing IAnjutaLoader interface,
> AnjutaCModule and AnjutaCPluginFactory, and rewriting
> AnjutaPluginManager to be a wrapper around libpeas. (I think we only
> need to implement the query method, the rest is available)

Yes, I'm agree it should be the "normal" use of libpeas in Anjuta but I 
don't think it's really useful neither for a few reasons:

1. The point 2 above means that we will probably not be able to use all 
language supported by libpeas anyway.

2. The current code in Anjuta is quite stable. I don't see any 
advantages for the user at the moment.

3. I have looked a bit at libpeas and there is a major difference, that 
you have already point in the bug reports. Anjuta plugin system is using 
GInterface while libpeas explicitly provides no access to underline 
GObjects, you have to use peas_extension_call. It means that libpeas can 
work with incomplete bindings which doesn't fully support GObject 
system. On the other hand it means that GObject implemented by plugins 
are not really GObject, it looks more like a simple function call. I 
suppose that function call of plugin functions with libpeas is slower. 
It doesn't matter for plugins written in python but it can make a 
difference for plugins in C.

I'm a bit annoyed to see that a new plugin system written several years 
after the one in Anjuta is less powerful. It looks like bindings are 
still not able to support all features of GLib which are used in Anjuta 
and stable since years.

Perhaps these features are not really needed and I'm a bit afraid that 
they become deprecated which will make us into troubles. In this case it 
could be useful to check which "advanced" features are really needed for 
Anjuta and see if we can find a replacement.

Another more optimist view is that these bindings are still quite new 
and just need more time to fully implement all Glib features.

Regards,

Sébastien