[Geany-Devel] New plugin loader mechanisms

[Matthew Brush]

On 15-03-18 01:23 PM, Dimitar Zhekov wrote:
> On 18.3.2015 г. 18:42, Thomas Martitz wrote:
>
>> - Global symbols. Plugins binaries have to export a number of global
>> symbols (geany_{functions,data,plugin}, plugin_{init,...,cleanup}). This
>> kind of sucks, because they pollute the global namespace (in theory).
>> Luckily on unix or win32 systems this is not a problem because they can
>> restrict the symbol visibility of shared libraries. It's still bad
>> practice. Ideally plugins should have zero global symbols, everything
>> being static or hidden to the plugin binary.
>
> Scope contains 20 source files and 22 headers. Using static is not an
> option, and marking everything global as hidden will be cumbersome,
> ugly, and easy to miss (inexperienced plugin developers are sure to miss
> symbols).
>

Why does it need so many globals? Shouldn't the only globals really be 
the stuff Geany requires? I'm wondering because one day it would be cool 
to able to do stuff like having multiple "instances" in-process and to 
allow a plugin per in-process "instance" or some stuff like this. With 
the additional userdata pointer, in theory one could make a big huge 
structure containing all their global (instance) state and have that 
passed around, and then there's less issue with symbols and multiple 
instances and such.

(I get that it's _not_ like that for Scope, but in theory it could've 
been and for new plugins it could be recommended).

>> [...]
>> 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.

Cheers,
Matthew Brush