[Geany-Devel] New plugin loader mechanisms
kugel at xxxxx
Wed Mar 18 19:21:30 UTC 2015
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
> 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
> 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
Don't think of the API as a restriction, instead it's the set of
functions that Geany developers maintain on your behalf.
More information about the Devel