[Geany-Devel] A direction for Geany

[Thomas Martitz]

Am 15.11.2013 15:34, schrieb Colomban Wendling:
> Le 11/11/2013 08:18, Lex Trotman a écrit :
>> [...]
>>
>> So I am starting this thread to try to get ideas on where Geany should
>> be headed.
>>
>> [...]
> #N	Seamless support for buffers with embedded 0 bytes

How do you define seamless? There's a patch that lets geany open binary 
files and it works pretty well in my experience.

>
> #N+1	Harder-to-break plugin API, maybe by hiding most things behind
> 	functions/accessors/setters
>


I agree. I would also say that improving the plugin API and making the 
life easier for plugin developers should be one of Geany's (or _the_) 
primary goals, given the stagnant (little man power, maintanance fears 
and it's generally hard to get stuff merged) for the core. This goal 
includes several pieces:

* harder to break API (as you have mentioned)
* accessible through multiple programming languages
* Bindings via GObject/introspection (this helps for both points)
* Formalized deprecation process
* Architecture to load plugins automatically/on demand, for e.g. 
filetypes plugins.

I would also like to see the strange way we export the API (via #define 
foo(...) a->b->foo(...)) sanitized. This might be even be required to 
achive some of the above points. We could easily use the linker to 
export/hide specific symbols in the geany executable. I think autotools 
have even built-in support for this. If plugins see the actual function 
prototypes (instead of defines) we can also more easily use optional GCC 
decorators, for example to have it warn on deprecated function usage.

With geany-plugins we do have a nice platform already for promoting and 
shipping plugins to users. Now we just need to make the actual process 
of writing plugins more inviting.

Best regards.