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.
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
