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