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
