[Geany-Devel] My non-C plugin roadmap

Thomas Martitz kugel at xxxxx
Sun Mar 29 09:24:42 UTC 2015

Am 29.03.2015 um 05:20 schrieb Lex Trotman:
> Thomas,
> Thanks for that, it now makes it clearer where you are going, and
> allows the individual steps to make more sense.
> I agree with your four problems (shortened):
> - linkage
> - keybindings
> - plugin context
> - allow for proxies
> My concern is that the solutions seem complex, though, having followed
> your attempts over time to address these issues, I do understand that
> some of the "simple" options don't actually cut it.
> Will need to think on it further.

Which of these steps seem complex to you in particular? Perhaps I can 
explain more detail on those to make things clearer for you. For me, 
none of these is really that complex, both in terms of conceptual 
complexity and lines of code changed. The most complex is probably the 
pluxy part, but still not really complex IMO (it's just a bit of 
refactoring of the internal load/unload functions functions and an API 
that allows plugins to add such functions for some filetypes). If 
anything, complexity is added by maintaining backward compatibility.

My current roadmap is such that it requires the least amount of changes 
to Geany core while still enabling libpeas-based and other non-C plugins 
to co-exist with standard plugins and not be second class citizens.

Other simple options (that provide a solution for the above, i.e. not 
current geanypy) don't exist. In fact, the other solution I have tried 
brought significant changes to Geany core to support libpeas-plugins 
directly in the core. Simple isn't always best too, we should strive to 
make all of this effort future proof but at the same time maintain 
backward compatibility.

Best regards.

More information about the Devel mailing list