[Geany-Devel] New plugin loader mechanisms
mbrush at xxxxx
Wed Mar 18 22:21:08 UTC 2015
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
> 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.
More information about the Devel