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).
>
>  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 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)

>  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.


>  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
> anjuta_glue_register_components. The issue is that we need
> working bindings supporting interface functions and callbacks.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=620516