Re: [anjuta-devel] libpeas

[Abderrahim KITOUNI <a kitouni gmail com>]

Hi,

2010/8/21, Sébastien Granjoux <seb sfo free fr>:
> Hi Abderrahim,
>
>  Here some comments about the discussion on libpeas in bug
> https://bugzilla.gnome.org/show_bug.cgi?id=621676
>
>
>  I think that exporting IAnjutaEditor* interfaces instead of a GtkTextView
> is much better at least for Anjuta needs. So I'm agree that it will be
> difficult to have the same plugin for gedit and anjuta. You can still put in
> the same shared library file both interfaces and have some common code. But
> anyway, in this case, we don't need to change anything in anjuta to make it
> compatible with gedit.
So it isn't as easy as it may seem ;-)


>  As Johannes, I think that moving all *Manager plugins in the core is a bad
> idea.
I don't have any opinion on this. Do as you like.

>  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
> function named "anjuta_glue_register_components" which
> register additional GLib types. Then the plugin manager just creates the
> plugin objects on demand using standard GLib function (g_object_new).
this requires that the plugin is able to register a GLib type
implementing an interface, which isn't possible in javascript now.
(e.g. it isn't possible in javascript now, I've made a patch for seed
[1]).

>  So, we can call peas_extension_call (ext, IANJUTA_TYPE_LOADER,
> "anjuta_glue_register_components"); to register all needed
> types and all the remaining code stay the same in Anjuta. This can be done
> in a plugin, so we can have a libpeas loader.
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.
So instead of anjuta_glue_register_components it will be
peas_register_types, and it is called automatically when loading the
plugin. The advantage of libpeas is that it works around language
bindings that cannot correctly register GTypes.

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 in libpeas)

>  I suppose that libpeas provides more services, like parsing .plugin file
> (this file contains meta information like plugin name, implemented
> interfaces...) checking dependencies and so on. I think this part is the
> main function of libpeas but it is independent from the language used by the
> plugin. I don't know how easy it will be to replace the corresponding code
> in Anjuta but the gain is null for the user and I think quite small for us
> as the code is already working and don't really need improvements for the
> moment.
Another feature it has is extension sets; having multiple plugins
implementing the same interface and call functions on all of them (in
gedit this is used for document-activatable plugins that are activated
once per document).

>  Writing a loader for javascript or valua plugin should be quite easy. We
> just need to write a new loader plugin that will load the javascript/vala
> code and call the javascript/vala function
We don't need a loader for Vala since it compiles to C (the vala
support plugin in anjuta is written in Vala)
> anjuta_glue_register_components. The issue is that we need
> working bindings supporting interface functions and callbacks.
Working bindings supporting interfaces are enough for most things
(only Builder, Debugger and Vcs need callbacks for now).

That's what I was thinking (I've written a javascript plugin loader
;-) [2]), but Johannes said it's better to use libpeas instead of our
own code so we don't have to maintain it.

Regards,
Abderrahim

P.S: Yesterday, I foundon libpeas IRC channel that someone is working
on making it possible to use normal interface method calls instead of
peas_extension_call, so it may be possible to port to libpeas at some
point.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=620516
[2] http://bitbucket.org/abderrahim/anjuta-jsloader/src you'll need
seed with the above patch.