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).
+1, I've always wanted a way to signal Geany "don't bother, it's just
going to crash you if you keep going". The only way I can see to
handle critical failures without a status return from there is to keep
a global variable and guard each function so it can't execute its
normal code, which is a bit of a pain and weird for users if the
plugin loads but doesn't do anything.
Another useful thing might be to provide a way to return a reason
message as well, then when Geany gets the failure return it can open
an error dialog and show the user a message that the plugin couldn't
be loaded, and show the reason string and maybe some bug-reporting
info or something.
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.
Incompatible plugins simply return false in geany_load_module() [I've
implemented a safety guard geany_load_modules() even though the abi/api
version check failed]. The plugin can also print the reason to
stdout/msgwin/error dialog from within that function, although IMO a
dialog is too intrusive.
I generally hate dialogs, but I think a plugin failing to load is a fine
use for one since it doesn't happen with high frequency, and just
dumping g_critical() or equivalent on the console is useless/confusing
if the user hasn't launched from a terminal (and doesn't realize about
Help->Debug Messages).
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.
Cheers,
Matthew Brush
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
