Hi Matthew and All,
@Matthew, I've looked at your dbus repo. I might not have understood how you were relating it to this, but to me it looks like you are just using the old plugin interface, rather than anything to do with a new interface.
@All,
Having reviewed what has been said in the thread to date, there is no real substance, so I think its likely that we may be talking about subtly different things. So to start the ball rolling here is an initial description of what I understand as the aims of this work and how I see it possibly being implemented.
As I see it the purpose is to define a new plugin interface to Geany that exposes all the required machinery through a set of GObjects which can be (semi) automatically interfaced to languages other than C, allowing Geany to have plugins written in multiple languages.
This new interface should provide at least the capabilities of the current plugin interface.
The way I see it being implemented, is not to change Geany's existing C structures into GObjects, rather, that the GObjects provide an interface to the existing C implementation and may not even map one to one with the existing structures.
This has several advantages,
1. the interface is somewhat isolated from the Geany implementation, allowing the implementation to evolve without causing a change in the interface seen by plugins. The current plugin interface is so thin that it is easy for changes to Geany to affect the interface. 2. the impact on the core implementation is minimised, so the impact on anything else happening in Geany itself is smaller. 3. The interface can be defined such that it is easy for plugins to use, independent of the underlying implementation
I see the GObjects as simply containing pointers to one or more of the Geany structures and the methods each being just a few calls to existing functions that operate on these structures.
There will still need to be code added to the existing implementation since it needs to create and destroy the GObjects as required and will have to emit signals on them when required. But this is a much less intrusive change compared to re-implementing core in GObjects. In fact it should be only additional code (albeit intertwined in the existing source), so minimising the likelihood of bugs being introduced into the existing Geany functionality.
Since the purpose is to support multiple languages, I think that some support for initialising and sharing interpretors/runtimes also needs to be created. It doesn't help someone to write Python or C# plugins if they have to figure out how to interface the Python interpretor or Mono runtime first. That should be done once for each language and be a loadable part of Geany. This process should also know how to find the plugins in the particular language, like Java ones in jar files, Python ones in directories with __init__.py in them etc. Sharing is needed to reduce the bloat that would occur if each plugin had to have a copy of the interpretor/runtime code
Hope this gives something to think about and throw things at.
Cheers Lex