On 15-03-18 03:55 PM, Thomas Martitz wrote:
Am 18.03.2015 um 23:21 schrieb Matthew Brush:
On 15-03-18 03:05 PM, Thomas Martitz wrote:
Am 18.03.2015 um 22:15 schrieb Matthew Brush:
[...]
void (*init) (GeanyPlugin *plugin, gpointer pdata);
Please make this gboolean. A plugin may have the correct API and ABI,
but be unable to startup / initialize for some reason. For example,
Scope requires scope.glade in the plugin data directory).
Thinking about it, if the plugin can't run because it's missing resource
files required for its operation, then I think it should be treaded like
incompatible plugins. This has the benefit that they will be attempted
to be loaded on the next startup if the user had previously selected it.
For resource files like say a GtkBuilder UI file, I'd agree, but there
may be some other cases, for example if a plugin dynamically loaded
some particular library (or variant of a library) based on user
configuration, it'd be useful to report to the user that the library
is wrong, or no longer available, or whatever.
Based on user configuration implies that it's a decision that is made
after the plugin's init(). If it allows the user to configure it without
this dependency then the plugin is considered operational, and init()
should not fail. Remember that a init() == FALSE would imply that the
plugin cannot be activated, and therefore not configured (i.e. you
cannot configure back so that it doesn't need the missing dependency).
Such custom requirements & errors are better placed in the plugin code
itself.
I'm thinking if the plugin loaded successfully, then it should be
operational too. Meaning that init() should not fail, but simply
activate the plugin. As outlined above, my proposal already covers the
case "compatible but not operational due to missing runtime
dependencies" you described.
For cases like GeanyPy which loads arbitrary Python scripts (which are
even fully executed on import), and in a language where Exceptions are
common (especially during development), it would probably be useful to
signal that the plugin script couldn't be loaded and maybe even be
able to provide a formatted traceback of the Python exception or such.
In my roadmap geanypy does not load scripts in its init(), but through a
separate API (so that the scripts integrate into the main plugin
manager). Anyway, geanypy init() isn't the right place because geanypy
can load multiple scripts, and which scripts can change afterwards after
init has run. And finally, all those scripts do not change the fact that
geanypy itself is operational, and this is what we're talking about.
I think I misunderstood the purpose of your `init()` function. I thought
it was a hook to allow the plugin manager/geany to be able to initialize
multiple plugins from the same .dll/module (ex. sub-plugins, etc). If
that's not the case, isn't the `init()` pointer in the struct basically
redundant as plugins could do their initialization in the roughly
equivalent `geany_load_module()` that is also called once per .dll?
For that matter, why not just leave the hooks all as loose functions (as
opposed to set into a structure), and just fix the prototypes to pass
around GeanyPlugin* and/or user_data, or whatever improvements? AFAIK
there's no issue with symbols/collisions if Geany just uses RTLD_LOCAL
when dlopen-ing the plugin module.
Cheers,
Matthew Brush
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
