Re: [Geany-Devel] New plugin loader mechanisms

2015-04-04 Thread Thomas Martitz
Am 29.03.2015 um 18:19 schrieb Colomban Wendling: So anyway, I think I'd be in favor of a failable init(), maybe like gboolean (*init) (..., GError **error); if we want to be able to report messages and the like. Or just let each plugin do the same msgwing_add() or whatever, but a common integr

Re: [Geany-Devel] New plugin loader mechanisms

2015-04-04 Thread Thomas Martitz
Am 30.03.2015 um 23:07 schrieb Thomas Martitz: Am 30.03.2015 um 14:57 schrieb Colomban Wendling: If `pdata` is provided in geany_plugin_register(), how does it get released? If it has to be a pointer to static data it's a bit limiting, and forces use of (static) globals, which is one thing tha

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-30 Thread Thomas Martitz
Am 30.03.2015 um 14:57 schrieb Colomban Wendling: If `pdata` is provided in geany_plugin_register(), how does it get released? If it has to be a pointer to static data it's a bit limiting, and forces use of (static) globals, which is one thing that this new API tries to avoid, doesn't it? We c

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-30 Thread Steven Blatnick
Re-sending as I don't see my email in https://lists.geany.org/cgi-bin/mailman/listinfo/devel Thanks. I didn't realize this. If you have a chance, maybe you could spot check my plugins: https://github.com/sblatnick/geany-plugins quick-* plugins external-tools tab-uti

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-30 Thread Steven Blatnick
Thanks. I didn't realize this. If you have a chance, maybe you could spot check my plugins: https://github.com/sblatnick/geany-plugins quick-* plugins external-tools tab-utils hide-menu I worry most of them have at non-api calls. Is there an easy way to tell

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-30 Thread Colomban Wendling
Hi, Le 30/03/2015 08:52, Thomas Martitz a écrit : >> […] >> >> ``` >> struct MyRealPlugin { >> RealPlugin parent; /* offset 0 has the Geany struct, so it's binary >> compatible */ >> /* plugin-specific fields here */ >> int the_game; >> }; >> ``` > > Now this is a big methodology ch

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-30 Thread Lex Trotman
[...] >>> In the future geany_plugin_register should be able to be used to >>> register plugins recursivly, by passing the appropriate GeanyPlugin >>> pointer, i.e. plugin A should be able to call >>> geany_plugin_register(plugin_B, ...) to realize pluxies. >> >> How does the proxy plugin create pl

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-29 Thread Thomas Martitz
Hi, in the hope I answered your pluxy-related questions in the other post I'll try to concentrate on the loader for this reply. Am 29.03.2015 um 19:04 schrieb Colomban Wendling: Hi, I'm answering both to the initial mail and this one here, so expect mixed citations. This will avoid raising

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-29 Thread Lex Trotman
[...] > All this said, a counter argument is that many plugins will load > external UI for configure(), and there we have no way to fail either. > > > So anyway, I think I'd be in favor of a failable init(), maybe like > > gboolean (*init) (..., GError **error); > > if we want to be able to

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-29 Thread Colomban Wendling
Hi, I'm answering both to the initial mail and this one here, so expect mixed citations. This will avoid raising the same points twice :) First, stuff extracted from the first mail. Disclaimer: Sorry if some remarks look slightly off-formulated, but while I altered them in the light of the last

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-29 Thread Colomban Wendling
Le 26/03/2015 00:22, Thomas Martitz a écrit : > […] >> >> What if instead of PluginHooks it was called `Plugin` (GeanyPlugin is >> taken, so for this discussion I'll use `Plugin` :) and instead of just >> the callback function pointers it contained the (possibly >> sub-)plugin's info, like this: >

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-29 Thread Colomban Wendling
Le 26/03/2015 00:16, Thomas Martitz a écrit : > Am 20.03.2015 um 19:45 schrieb Dimitar Zhekov: >> >>> >>> 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. >> >> There seem

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-29 Thread Colomban Wendling
Hi, Le 18/03/2015 18:11, Steven Blatnick a écrit : > > On 03/18/2015 10:42 AM, Thomas Martitz wrote: >> Currently geany exports a pointer to a struct, that contains more >> structs, which contain function points to the API functions. >> Fortunately this is nicely hidden to developers via macros.

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-28 Thread Thomas Martitz
Hello, based on the discussion I refined my proposal (see below). Additionally I have implemented all of this, including updating demoplugin.c, see [1]. And last but not least, I have a fully working implementation of proxy plugins aka pluxies (in fact, I simply updated my year-old branch to

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-27 Thread Thomas Martitz
Am 26.03.2015 um 18:47 schrieb Dimitar Zhekov: On 26.3.2015 г. 01:16, Thomas Martitz wrote: Now, do we really want the plugins to run arbitrary resource checking code, and display their own error messages, only because they are queried (or registered, as you put it), each time the list is build

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-26 Thread Dimitar Zhekov
On 26.3.2015 г. 01:16, Thomas Martitz wrote: Now, do we really want the plugins to run arbitrary resource checking code, and display their own error messages, only because they are queried (or registered, as you put it), each time the list is build? Yes plugins should be able to run arbitrary

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-25 Thread Matthew Brush
On 15-03-25 04:22 PM, Thomas Martitz wrote: Am 18.03.2015 um 22:55 schrieb Matthew Brush: [snip] ``` static Plugin my_plugin = { .name= "Foo", .version = "0.1", .author = "Me", .description = "Foo plugin", .api_min = 200, .abi_ver = GEANY_ABI_VERSION, .ini

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-25 Thread Matthew Brush
On 15-03-25 04:22 PM, Thomas Martitz wrote: Am 18.03.2015 um 22:55 schrieb Matthew Brush: On 15-03-18 09:42 AM, Thomas Martitz wrote: tl;dr <- Key functions gboolean geany_load_module(GeanyPlugin *, GModule *) What is the GModule* for? Is it a .dll that Geany opened on behalf of the plugin

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-25 Thread Thomas Martitz
Am 18.03.2015 um 22:55 schrieb Matthew Brush: On 15-03-18 09:42 AM, Thomas Martitz wrote: tl;dr <- Key functions gboolean geany_load_module(GeanyPlugin *, GModule *) What is the GModule* for? Is it a .dll that Geany opened on behalf of the plugin based on selection in Plugin Manager? That

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-25 Thread Thomas Martitz
Am 20.03.2015 um 19:45 schrieb Dimitar Zhekov: 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. There seem like two different things to me. The first thing a loader needs t

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-20 Thread Dimitar Zhekov
On 18.3.2015 г. 23:15, Matthew Brush wrote: 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 glo

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-20 Thread Dimitar Zhekov
On 18.3.2015 г. 22:51, Thomas Martitz wrote: Am 18.03.2015 um 21:23 schrieb Dimitar Zhekov: On 18.3.2015 г. 18:42, Thomas Martitz wrote: Do you generally like or support my proposal? Yes, because the final goal is to be able to support different languages with gtk+ bindings, like/with libp

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-20 Thread Dimitar Zhekov
On 19.3.2015 г. 00:05, 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

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-19 Thread Thomas Martitz
Am 19.03.2015 um 23:34 schrieb Lex Trotman: On 19 March 2015 at 09:16, Thomas Martitz wrote: There is no other way of loading C shared libraries and registering them as plugins. Doesn't Geany already load dlls local and extract the symbols it wants via dlsym()? dlsym() takes an argument of the

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-19 Thread Lex Trotman
On 19 March 2015 at 09:16, Thomas Martitz wrote: > Am 18.03.2015 um 22:23 schrieb Lex Trotman: >> >> Hi Thomas, >> >> In general this looks like an improvement to the current method of >> setting up plugins, except it continues to require the plugin .so file >> to be dlloaded just to populate the

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-19 Thread Thomas Martitz
Am 19.03.2015 um 01:19 schrieb Matthew Brush: 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); Pleas

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-18 Thread Matthew Brush
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 cor

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-18 Thread Thomas Martitz
Am 18.03.2015 um 22:23 schrieb Lex Trotman: Hi Thomas, In general this looks like an improvement to the current method of setting up plugins, except it continues to require the plugin .so file to be dlloaded just to populate the plugin manager. That will run the dll initialization code, and may

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-18 Thread Thomas Martitz
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 /

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-18 Thread 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

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-18 Thread Thomas Martitz
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 direc

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-18 Thread Matthew Brush
On 15-03-18 09:42 AM, Thomas Martitz wrote: Hello, tl;dr -> scroll down I am working on a new plugin architecture that deals with some of the shortcomings of the current state. My primary motivation is to be able to use libpeas to load plugins, both C and non-C (Python!), as you might have lear

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-18 Thread Lex Trotman
Hi Thomas, In general this looks like an improvement to the current method of setting up plugins, except it continues to require the plugin .so file to be dlloaded just to populate the plugin manager. That will run the dll initialization code, and may therefore break Geany. Have you thought abou

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-18 Thread 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 the

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-18 Thread Thomas Martitz
Am 18.03.2015 um 21:23 schrieb Dimitar Zhekov: 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

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-18 Thread Dimitar Zhekov
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 i

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-18 Thread Thomas Martitz
Am 18.03.2015 um 18:11 schrieb Steven Blatnick: I personally hope whatever the group decides to do with the plugins doesn't involve requiring a rewrite of all of them, because we'll surely lose plugins and supporters that way. Geany developers are committed to maintain compatibility for exis

Re: [Geany-Devel] New plugin loader mechanisms

2015-03-18 Thread Steven Blatnick
I personally hope whatever the group decides to do with the plugins doesn't involve requiring a rewrite of all of them, because we'll surely lose plugins and supporters that way. Concerning some of your perceived shortcomings: On 03/18/2015 10:42 AM, Thomas Martitz wrote: Currently geany expor

[Geany-Devel] New plugin loader mechanisms

2015-03-18 Thread Thomas Martitz
Hello, tl;dr -> scroll down I am working on a new plugin architecture that deals with some of the shortcomings of the current state. My primary motivation is to be able to use libpeas to load plugins, both C and non-C (Python!), as you might have learned from other threads I started. However