[Geany-devel] libpeas and geany's plugins

Lex Trotman elextr at xxxxx
Mon Feb 7 00:05:07 UTC 2011


On 7 February 2011 05:00,  <joshua.rh at 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 at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
>



More information about the Devel mailing list