Created attachment 163707 [details] [review]
add initial gobject-introspection support

Created attachment 163708 [details] [review]
python loader plugin

Review of attachment 163707 [details] [review]:

This one looks good! Hope I find some time to commit it.

Review of attachment 163708 [details] [review]:

Thanks for your work. I would suggest to port the whole anjuta plugin system to libpeas though as this will give us python and javascript loaders automatically (and probably vala and others soon).

The python loader is working fine and I think it will be quite easy to use other language, the issue is rather the binding for the whole libanjuta.

Replacing anjuta plugin system with libpeas is quite some work. I think that anjuta plugin system is still more advanced than libpeas, it supports plugin dependencies.

It's still interesting to use libpeas in the future but then I think something really nice will be to be able to write common plugin for both Anjuta and GEdit. It needs more than just using libpeas, it needs common interface but I think it's possible especially for simple plugin which are just adding one menu item.

(In reply to comment #5)
> The python loader is working fine and I think it will be quite easy to use
> other language, the issue is rather the binding for the whole libanjuta.

Well, PyGI which uses gobject-introspection will allow us to avoid writing bindings mostly. There is just some stuff in libanjuta which isn't really binding friednyl.

> Replacing anjuta plugin system with libpeas is quite some work. I think that
> anjuta plugin system is still more advanced than libpeas, it supports plugin
> dependencies.

As far as I found out it supports most of the things that anjuta needs. It's not perfect yet but having a common libraries reduces our maintenance workload and might make it easier to support future technologies.
 
> It's still interesting to use libpeas in the future but then I think something
> really nice will be to be able to write common plugin for both Anjuta and
> GEdit. It needs more than just using libpeas, it needs common interface but I
> think it's possible especially for simple plugin which are just adding one menu
> item.

It might be interesting but the APIs are so different that I think it hardly make sense to push much into that direction.

Review of attachment 163708 [details] [review]:

Comitted - thanks!

Review of attachment 163708 [details] [review]:

Wrong patch - sorry...

Review of attachment 163707 [details] [review]:

Introspection support was comitted - thanks!

I've taken a deeper look at libpeas and it seems to be too much work to adapt to the libpeas way of doing things.

(In reply to comment #5)
> The python loader is working fine and I think it will be quite easy to use
> other language, the issue is rather the binding for the whole libanjuta.
> 
> Replacing anjuta plugin system with libpeas is quite some work. I think that
> anjuta plugin system is still more advanced than libpeas, it supports plugin
> dependencies.
Tht's not a problem. AFAICT, it does support dependencies. It doesn't support plugin queries based on metadata but that can be easily added on top of it.

The problem with libpeas is that it is very different from what we're doing with anjuta. The biggest difference is that it doesn't expose plugin objects directly but rather a PeasExtension. What this means is that instead of say:

cur_doc = ianjuta_document_manager_get_current_document (docman, NULL);

we would use:

peas_extension_call (docmanext, IANJUTA_TYPE_DOCUMENT_MANAGER,
                     "get_current_document", NULL, &cur_doc);

The easiest way for this to work painlessly IMHO is to move all the *Manager plugins to the core.

> It's still interesting to use libpeas in the future but then I think something
> really nice will be to be able to write common plugin for both Anjuta and
> GEdit. It needs more than just using libpeas, it needs common interface but I
> think it's possible especially for simple plugin which are just adding one menu
> item.

That's indeed interesting, but the fact that Anjuta doesn't expose a GtkTextView as editor (a GtkWidget is quite useless from a plugin POV) makes it nearly impossible to do so.

> cur_doc = ianjuta_document_manager_get_current_document (docman, NULL);
> 
> we would use:
> 
> peas_extension_call (docmanext, IANJUTA_TYPE_DOCUMENT_MANAGER,
>                      "get_current_document", NULL, &cur_doc);
>

That's indeed quite ugly and I wasn't aware of that until now. This would that we have to change a lot of code which I would definitely like to avoid.

> The easiest way for this to work painlessly IMHO is to move all the *Manager
> plugins to the core.

Well, that's not an option as it would completely brake the design of anjuta.

> That's indeed interesting, but the fact that Anjuta doesn't expose a
> GtkTextView as editor (a GtkWidget is quite useless from a plugin POV) makes it
> nearly impossible to do so.

Well, anjuta exports the IAnjutaEditor* interfaces for good reason to be editor independent (and to avoid that plugins do things we don't want them to do). And there is far more to be able to use gedit plugins in anjuta and vice versa so I guess that will remain a dream for now.

So, overall, as the C API for libpeas plugins is definitly not usable currently for anjuta (see above) I am quite in favour of adding the python loader. It was also pointed out recently on desktop-devel-list that it is impossible to use python and javascript in the same process and as such I would rather go with the python path for now.

Review of your patch follows...

Review of attachment 163708 [details] [review]:

OK, so that looks good overall!

Is it possible to port the python debugger Sébastien once developed to introspection (possibly fixing some introspection comments)? That would be a great proof-of-concept!

We should also include a sample python plugin IMHO.

Thanks again for your work and for investigating libpeas.

::: plugins/python-loader/anjuta-python-loader.plugin.in
@@ +1,2 @@
+[Anjuta Plugin]
+Name=Python loader

This should be _Name and _Description here because those fields should be translated.

::: plugins/python-loader/plugin.c
@@ +24,3 @@
+
+#include <libanjuta/anjuta-debug.h>
+#include <libanjuta/interfaces/libanjuta-interfaces.h>

I would prefer to have only a ianjuta-plugin-factory.h included here.

@@ +113,3 @@
+
+	/* Retrieve the Python type for anjuta plugin */
+	m = PyImport_ImportModule ("gi.repository.Anjuta");

So that means we use introspection, right? Cool!

Actually I fixed the things mentioned in my local copy yesterday, so you don't need to update the patch.

What I found out so far:

* pygobject doesn't allow to implement interfaces as of yet. That means implementing python plugins impossible for some areas of anjuta

* we need a sample plugin

I am willing to merge those patches when we have a sample plugin that proves that things are working to some extend. I think it can still be useful in some simpler plugins like interacting with the editor for example. We cannot port the (win)pdb debugger plugin yet though as it requires interfaces.

(In reply to comment #13)
> Actually I fixed the things mentioned in my local copy yesterday, so you don't
> need to update the patch.
> 
> What I found out so far:
> 
> * pygobject doesn't allow to implement interfaces as of yet. That means
> implementing python plugins impossible for some areas of anjuta
That's really weird. What did you try and what problem did you get?
 
> * we need a sample plugin
Do you mean a project template or just a sample plugin like this one?
http://bitbucket.org/abderrahim/anjuta-pyloader/src/tip/sample/
 
> I am willing to merge those patches when we have a sample plugin that proves
> that things are working to some extend. I think it can still be useful in some
> simpler plugins like interacting with the editor for example. We cannot port
> the (win)pdb debugger plugin yet though as it requires interfaces.

The problem with the winpdb plugin is that pygobject doesn't support passing callbacks to virtual functions (i.e. passing callbacks to callbacks), so the interfaces that cannot be implemented are Builder, Debugger and Vcs (and Iterable but that probably doesn't count).

Hi!

> > * pygobject doesn't allow to implement interfaces as of yet. That means
> > implementing python plugins impossible for some areas of anjuta
> That's really weird. What did you try and what problem did you get?

I am referring to http://live.gnome.org/PyGI/Marshalling

<quote>
Interfaces are supported as subtypes of gobject.GInterface.

Since virtual functions are not supported yet, one cannot really implement an interface in Python. 
</quote>

> > * we need a sample plugin
> Do you mean a project template or just a sample plugin like this one?
> http://bitbucket.org/abderrahim/anjuta-pyloader/src/tip/sample/

Something like that, loosely based on the existing C sample plugin, e.g. define some action, show some dialog. Bonus points for a project template of course ;)

> The problem with the winpdb plugin is that pygobject doesn't support passing
> callbacks to virtual functions (i.e. passing callbacks to callbacks), so the
> interfaces that cannot be implemented are Builder, Debugger and Vcs (and
> Iterable but that probably doesn't count).

Hmm, how do they handle gtk_container_foreach() then? The ultimate goal is to allow access to these from introspection bindings allowing simple API changes (for 3.0) but I would like to know how this should be handled exactly.

> <quote>
> Interfaces are supported as subtypes of gobject.GInterface.
> 
> Since virtual functions are not supported yet, one cannot really implement an
> interface in Python. 
> </quote>

hmm, seems fixed
https://bugzilla.gnome.org/show_bug.cgi?id=602736
 
> Hmm, how do they handle gtk_container_foreach() then? The ultimate goal is to
> allow access to these from introspection bindings allowing simple API changes
> (for 3.0) but I would like to know how this should be handled exactly.

This one also:
https://bugzilla.gnome.org/show_bug.cgi?id=603095

Is there anything left that we cannot fix in a very simply way in our C API?

(In reply to comment #15)
> Hmm, how do they handle gtk_container_foreach() then? The ultimate goal is to
> allow access to these from introspection bindings allowing simple API changes
> (for 3.0) but I would like to know how this should be handled exactly.

I meant you cannot override it in python, not that you cannot call it.

The (not so easy) way to fix this in the C API is to have an object be passed to these functions instead of a callback. I don't know how easy it would be to do this, I'll try to investigate later

Review of attachment 163708 [details] [review]:

Committed to master

Closing this bug as all patches have been committed. Discussion for the python debugger interfaces should better continue on the mailing list.