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.