Re: [anjuta-devel] libpeas

[Ondřej Pelech <ondra pelech gmail com>]

Hello,

maybe you could ask the author[0] of libpeas, whether the library will
support these advanced features that are needed for anjuta.

email: steve_at_istique_dot_net
mailing list: libpeas-list gnome org
IRC: #libpeas on irc.gnome.org

[0] http://live.gnome.org/SteveFr%C3%A9cinaux

2010/8/21 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
> _______________________________________________
> anjuta-devel-list mailing list
> anjuta-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/anjuta-devel-list