On 7 February 2011 05:00, joshua.rh@comcast.net wrote:
Replacing the existing interface would require all current plugins to be re-written. IMHO thats unacceptable without a long deprecation period to allow plugin maintainers time to do so.
Therefore you have to make the new interface an additional one. You can create the introspect-able objects you want to give a clean simple interface without relating it to an existing largely non-oo interface.
How would you relate these interface GObjects to the existing internal data structures that contain the data?
That way we'd have C/Python/JavaScript support out of the box, and would avoid duplication work/code.? Would it be difficult to port geany's API to libpeas?
Probabably, its not designed for that. (caveat I have only glanced at libpeas doco)
Cheers Lex
Maybe that would work. What if we wrote the libpeas plugin, and if it seems like it would be good to have libpeas as the main plugin interface (for maintainabilities sake), we can slowly port existing plugins. If not, we'd still have the libpeas/gobject plugin for python/js plugins. What does everyone think of that?
Josh
Hi Josh,
The "problem" with this is that Geany currently doesn't support sub-plugins, ie plugins having plugins. The subplugins would have to be managed via a separate UI run by your plugin, not Tools->Plugin Manager where the "first class" plugins are managed. This is less than desirable from a user point of view.
Nick has talked about adding subplugin support in the past, but he certainly hasn't rushed in to do it so I don't know how hard it would be.
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel