[Geany-Devel] New plugin loader mechanisms

[Thomas Martitz]

Am 18.03.2015 um 18:11 schrieb Steven Blatnick:
> I personally hope whatever the group decides to do with the plugins 
> doesn't involve requiring a rewrite of all of them, because we'll 
> surely lose plugins and supporters that way.
>

Geany developers are committed to maintain compatibility for existing 
plugins to new Geany versions, and we go through great length to make 
that possible. Most of the time at worst plugins need to be recompiled. 
That said, there may be times were a severe break is necessary but we 
really do our best to avoid that.

Following that, my plans are "on-top" of the current loader. While it 
would kind of deprecated the current loader, plugins written against it 
(all current plugins) will keep working without changes or recompiling. 
This is purely for new plugins or those that voluntarily adapt the new 
loader.

> Concerning some of your perceived shortcomings:
>
> On 03/18/2015 10:42 AM, Thomas Martitz wrote:
>> Currently geany exports a pointer to a struct, that contains more 
>> structs, which contain function points to the API functions. 
>> Fortunately this is nicely hidden to developers via macros. But due 
>> to gtkbuilder all functions and nothing prevents plugins from 
>> accessing these. And the macros are awkward and strange anyway. There 
>> is currently the linkage-cleanup PR in the works which improves this 
>> by actually exporting the API functions, and _only_ the API functions 
>> to plugins. 
> Maybe I'm completely wrong on this from an architecture perspective, 
> but part of what I like about writing plugins for geany is 
> accessibility.  If we only get access to a subset of functions, then 
> it seems less flexible what our plugins can actually do.  Yes, this 
> allows us to write bad plugins that can do some sloppy things, but I 
> say "so what".  They are plugins. Someone would have to go out of 
> their way to install most plugins outside of geany-plugins, and there 
> is some vetting for that list of plugins.  I say by keeping the 
> restrictions minimal on what plugins can access, we can get more 
> powerful plugins and not block off potential plugins by our 
> over-abstraction.
>
> Take chrome/chromium browser, for instance.  They basically have 
> restricted all plugins to be at most a button on the toolbar or 
> effecting web pages.  There seems to be no possible way to write a 
> plugin to get vertical tabbing I so appreciate in firefox (and geany 
> for that matter) because chrome seems to have this stuck-up mac 
> attitude that it's the way they intended, no customization allowed, 
> "mission accomplished <https://www.youtube.com/watch?v=MgSQA1jqFpM>".  
> Maybe I'm wrong, maybe that's not chrome's motive, but I certainly 
> don't like the lack of flexibility of their plugin architecture.  (If 
> anyone knows a way on linux to get vertical tabs in chrome, that would 
> be awesome ;-)
>
> I suppose you could argue that having access to almost everything 
> requires more frequent updating of plugins, but personally I haven't 
> had more than one or two line changes with any update to geany.  Plus 
> then we have to worry more about plugin support and it's own set of bugs.
>
> That's just my opinion.  Thoughts?

We never supported plugins that call non-API functions. In fact, that 
it's possible now is a mistake. And the reason is simple: We can only 
maintain a defined API. We are not able to able to provide backwards 
compatibility for plugins that call functions we cannot know about.

Therefore we define the API, and commit to support that API. If you 
think the API is insufficient, then please speak up, describe your use 
case and get the function(s) you need added to the API. Then we can 
support these function and keep your plugin working. And that means that 
we keep your users happy. I think we are generally not that rigid at all 
as to what's added to the API, but it has to be formally defined. I 
think this is also in your interest, as it means less headaches for you 
going forward.

Don't think of the API as a restriction, instead it's the set of 
functions that Geany developers maintain on your behalf.

Best regards.