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
Le 06/02/2011 19:00, joshua.rh@comcast.net a écrit :
[...]. 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?
That it would probably be a huge piece of work, but that'd be cool (support for many languages using GI) if it works. So if you would do it... :)
However, Geany devs don't seem to be huge fans of GObject code, so not sure how much painful it would be for them if it get integrated to the core...
My 2¢ Colomban
On 7 February 2011 06:28, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 06/02/2011 19:00, joshua.rh@comcast.net a écrit :
[...]. 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?
That it would probably be a huge piece of work, but that'd be cool (support for many languages using GI) if it works. So if you would do it... :)
However, Geany devs don't seem to be huge fans of GObject code, so not sure how much painful it would be for them if it get integrated to the core...
I suspect its more a case that there is a lot of existing non-GObject code and a lot of effort would be required to convert it for little gain (for the Geany core).
Making the GObjects just in the interface and having them wrap a pointer to the existing structures means no changes to core are needed immediately. They might occur over time if that has any advantage for core but thats a different question.
Cheers Lex
My 2¢ Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sun, 06 Feb 2011 20:28:35 +0100, Colomban wrote:
Le 06/02/2011 19:00, joshua.rh@comcast.net a écrit :
[...]. 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?
That it would probably be a huge piece of work, but that'd be cool (support for many languages using GI) if it works. So if you would do it... :)
However, Geany devs don't seem to be huge fans of GObject code, so not
Not entirely true. At least for me, I didn't know much about GObject code when I began writing Geany. And (much) later, I played with GObject code and think it's quite ok though it still doesn't feel like real object-oriented code but this is probably more a limitation of C, obviously :D. To sum it up, I do like GObject, to some extend, but I'm afraid it's just too late for Geany's code base to be converted. At least for me, as my free time doesn't allow such thoughts.
This is also the reason why I don't participate such discussions about big structural changes. I just don't want to get in the way of new developments without having the chance to contribute anything useful in a time period will we are able to live in...:D
Regards, Enrico
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