Hello,
I was asked to share a bit about my roadmap regarding plugins. I'll try to give you a better idea with this post.
My ultimate goal is to implement a clean and maintainable way to support non-C plugins, preferably using existing widely used techniques. I concluded that libpeas[1] in conjunction with gobject-introspection can provide the base for this. Since Geany is not at all prepared for this I have several infrastructure which I do want to get merged into Geany. When Geany core is sufficiently setup for this, the non-C plugin enablement can happen outside the core, as a plugin, to stabilize there.
So, here's the set of infrastructure changes for the core. Please let me stress that all of this will happen in backward-compatible manner, no existing plugins break as part of this.
- linkage-cleanup (PR#429) - This changes the way plugins access Geany API functions. Instead of exporting a pointer to a struct of structs of API function pointers, now the APIs are exported directly. This work also includes an effort to stop exporting all function (we do this currently as a workaround to allow gtkbuilder to work), so *only* API function are exported and plugins cannot call internal function anymore. This change is also required to allow gobject-introspection to find geany functions at runtime (through g_module_symbol()) in the future. - new API functions for registering keybindings (PR#376). The current API functions do not allow context information to be stored and passed to the key handler function. This makes it very hard for non-C plugins to use these function. So what's needed are key handlers that get the necessary context information. This allows interprepted language plugins to register keybindings. - A new plugin loader mechanism (a thread about this is already running on the devel list): Similarly to the keybindings, the plugin_* functions implemented by plugins do not carry any context information, making it hard for non-C plugins to implement them properly. Therefore a new loader mechaism is needed so that the context information can be passed. The loader works such that an API function is called to register a function pointer table. This is crucial to possibly support plugins that register other plugins (so called pluxies) which is simply not possible with the current mechaism. The current loader is kept for backwards compatibility (but will not receive new features). - New API functions to allow plugins to act as proxy plugins (pluxies). These pluxies can then implement whatever is needed to execute code in the in the actual plugin, like invoking an interpreter or firing up a java vm. The pluxies call the new loader's API function on behalf of the actual plugin. The API function to implement the pluxies is a simple geany_register_pluxy() that, much like the normal plugin loader, that pluxies use to pass a function pointer table which implements the necessary hooks (probe(), load() and unload())
Once this is in place in the core, my roadmap contains the following items, which are implemented (at least initially) in a plugin, so no further changes to the cure should be necessary. - Modify geanypy to use the new pluxy APIs. This will finally enable geanypy to show the python plugins in the normal PM dialog and support keybindings - Create a new pluxy that supports libpeas-based plugins (codename: peasy). Peasy will use libpeas to load plugins and their metadata. - Part of the peasy work is also work on creating vala and gobject-introspection bindings for Geany's API functions, so that we can support python, javascript and lua out of the box.
This is my roadmap so far. It changed quite a bit since I started this non-C-plugins effort a year ago, but I hope it will be good for everyone. Please share your opinions on this or ask questions.
Best regards.
Hi Geany lovers,
I have a very annoying bug in geany...its has to do with autocompletion.
I have a dark theme.
When autocompletion activate to show me the list of options, the box is to small, I cant see all options, and i can't even see more than 10chars per option, this is a problem, the box dosn't scale automatically, and in some struct members you can't see them, you don't know who is who, if they have similar names... :S,
The colors of the box is white :S, not the same color has the backgroud of IDE, or the theme used...
Is there any way to change it by config some file, etc?
regards tux
What version of Geany and what operating system with what window manager?
On 29 March 2015 at 14:39, lmx lmx1@sapo.pt wrote:
Hi Geany lovers,
I have a very annoying bug in geany...its has to do with autocompletion.
I have a dark theme.
When autocompletion activate to show me the list of options, the box is to small, I cant see all options, and i can't even see more than 10chars per option, this is a problem, the box dosn't scale automatically, and in some struct members you can't see them, you don't know who is who, if they have similar names... :S,
The autocomplete menu re-sizes for me.
The colors of the box is white :S, not the same color has the backgroud of IDE, or the theme used...
Depends on OS, but it should get its colours from the OS GTK theme (not the editor window theme).
Cheers Lex
Is there any way to change it by config some file, etc?
regards tux _______________________________________________ Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
On 15-03-28 08:39 PM, lmx wrote:
Hi Geany lovers,
I have a very annoying bug in geany...its has to do with autocompletion.
I have a dark theme.
When autocompletion activate to show me the list of options, the box is to small, I cant see all options, and i can't even see more than 10chars per option, this is a problem, the box dosn't scale automatically, and in some struct members you can't see them, you don't know who is who, if they have similar names... :S,
I've noticed similar weird scaling issues, especially if you start with a smallish font size set, and then zoom in a lot, the autocomplete doesn't resize, but for me it's only the vertical auto-complete item height that fails to match the font size, like this:
http://i.imgur.com/phX0PdN.png
Not sure if that's the same thing as you have.
The colors of the box is white :S, not the same color has the backgroud of IDE, or the theme used...
That part is controllable by themes, although there's some bug somewhere that colors can get stuck even if you change themes. For example if you activate the Retro theme (which is one of few that changes theme dramatically of autocomplete box), and then change to another theme, it gets stuck on the Retro one and never resets.
Cheers, Matthew Brush
On 29/03/15 19:56, Matthew Brush wrote:
On 15-03-28 08:39 PM, lmx wrote:
Hi Geany lovers,
I have a very annoying bug in geany...its has to do with autocompletion.
I have a dark theme.
When autocompletion activate to show me the list of options, the box is to small, I cant see all options, and i can't even see more than 10chars per option, this is a problem, the box dosn't scale automatically, and in some struct members you can't see them, you don't know who is who, if they have similar names... :S,
I've noticed similar weird scaling issues, especially if you start with a smallish font size set, and then zoom in a lot, the autocomplete doesn't resize, but for me it's only the vertical auto-complete item height that fails to match the font size, like this:
http://i.imgur.com/phX0PdN.png
Not sure if that's the same thing as you have.
I am using debian amd64, with mate desktop.my window manager is the standard MARCO based on methacity from gnome2.. I have even a diferent situation :S
I am using the previous release of Geany 1.23.1, and not the last one, I don't know if changed something about this?
with normal size of text: http://i.imgur.com/QNYg2FC.png
with scalled size of text: http://i.imgur.com/7kOGCRm.png
like you see i have no issues with the scalled image...apart from do not get all in the screen cuz is too big lol
With normal text, auto-complete should find the size of the biggest element or something and scalle acordingly imho...
My theme is vibrant colours, or ink colours...is something that I found , and it turns out to be more visible with my eyes :)
The colors of the box is white :S, not the same color has the backgroud of IDE, or the theme used...
That part is controllable by themes, although there's some bug somewhere that colors can get stuck even if you change themes. For example if you activate the Retro theme (which is one of few that changes theme dramatically of autocomplete box), and then change to another theme, it gets stuck on the Retro one and never resets.
if there is some directive to auto-complete foreground and background it would be nice, or the Autocomplete box, could get the foreground and background colours of the theme ;)
well, with this I already discovered that with scalling editor, I should be able to see the several items, its not ideal, but better than nothing :)
thanks to Mathew and Lex :)
cheers, tux
[...]
I am using the previous release of Geany 1.23.1, and not the last one, I don't know if changed something about this?
The autocomplete box is generated by Scintilla (another project whose editor widget we use). There were quite a lot of changes between 1.23.1 and 1.24.1 the current (and already a year or so old) release. Too long ago to check if they explicitly addressed this, but the box does re-size to fit the longest item for me in 1.24.1.
Cheers Lex
[...]
Hi guys,
I am running geany without problems for some years from now...
today i experienced a weird thing...
I decided to run vangrind against my code...
well...now i can't use gdb :(
I can compile and run the process, but not debug it...
when I try to open a file with fopen or use calloc, or malloc, the geany debuger trows me some erros :(
like this for malloc/calloc:
"Can't find a source file "/home/aurel32/eglibc/eglibc-2.17/malloc/malloc.c""
"home/aurel"??? why? wtf..
Another errors: when I try to access a FILE * pointer, for a regular file, that exists!
Can't find a source file "/home/aurel32/eglibc/eglibc-2.17/libio/iofgets.c"
I can't work...but I can compile??don't understand this...
for what I understand valgrind is controlling the binary file, and this process, is afther that "corrupted" right ??
but even then, deleting it, compiling again with gcc...running it ok, debuguing it...i can't.
some info from valgrind report fther running my code against it:
==9423== Invalid write of size 4 ==9423== at 0x4E87037: _IO_vfscanf (vfscanf.c:1857) ==9423== by 0x4E8EBC4: __isoc99_vsscanf (isoc99_vsscanf.c:43) ==9423== by 0x4E8EB46: __isoc99_sscanf (isoc99_sscanf.c:32) ==9423== by 0x40143B: file_to_holder (ihx.c:267) ==9423== by 0x400E59: ihx_read (ihx.c:130) ==9423== by 0x40159B: main (main.c:16) ==9423== Address 0x51df44d is 13 bytes inside a block of size 16 alloc'd ==9423== at 0x4C2B514: calloc (vg_replace_malloc.c:593) ==9423== by 0x4013E1: file_to_holder (ihx.c:261) ==9423== by 0x400E59: ihx_read (ihx.c:130) ==9423== by 0x40159B: main (main.c:16) ==9423==
why is geany looking for "/home/aurel32/eglibc/eglibc-2.17/malloc/malloc.c"" when a malloc intruction occurrs in the code???
does any one have any idea how to solve this?
thanks in advance
regards tux
On 15-04-04 03:45 PM, lmx wrote:
Hi guys,
I am running geany without problems for some years from now...
today i experienced a weird thing...
I decided to run vangrind against my code...
well...now i can't use gdb :(
I can compile and run the process, but not debug it...
when I try to open a file with fopen or use calloc, or malloc, the geany debuger trows me some erros :(
like this for malloc/calloc:
"Can't find a source file "/home/aurel32/eglibc/eglibc-2.17/malloc/malloc.c""
"home/aurel"??? why? wtf..
Another errors: when I try to access a FILE * pointer, for a regular file, that exists!
Can't find a source file "/home/aurel32/eglibc/eglibc-2.17/libio/iofgets.c"
I can't work...but I can compile??don't understand this...
for what I understand valgrind is controlling the binary file, and this process, is afther that "corrupted" right ??
but even then, deleting it, compiling again with gcc...running it ok, debuguing it...i can't.
some info from valgrind report fther running my code against it:
==9423== Invalid write of size 4 ==9423== at 0x4E87037: _IO_vfscanf (vfscanf.c:1857) ==9423== by 0x4E8EBC4: __isoc99_vsscanf (isoc99_vsscanf.c:43) ==9423== by 0x4E8EB46: __isoc99_sscanf (isoc99_sscanf.c:32) ==9423== by 0x40143B: file_to_holder (ihx.c:267) ==9423== by 0x400E59: ihx_read (ihx.c:130) ==9423== by 0x40159B: main (main.c:16) ==9423== Address 0x51df44d is 13 bytes inside a block of size 16 alloc'd ==9423== at 0x4C2B514: calloc (vg_replace_malloc.c:593) ==9423== by 0x4013E1: file_to_holder (ihx.c:261) ==9423== by 0x400E59: ihx_read (ihx.c:130) ==9423== by 0x40159B: main (main.c:16) ==9423==
why is geany looking for "/home/aurel32/eglibc/eglibc-2.17/malloc/malloc.c"" when a malloc intruction occurrs in the code???
does any one have any idea how to solve this?
Hi,
Geany doesn't have a debugger or Valgrind support, so I guess you are using one of the debugging plugins? I would try to clean build and get it running outside of Geany from the command line, after your build issues are sorted out (ex. it looks like you're linking "eglibc" in your home directory rather than some system-wide C stdlib, maybe on purpose?), I bet it will work with any of the debugging plugins. Valgrind should be totally unrelated to any of this.
Cheers, Matthew Brush
Hi Matthew,
thanks for the help :)
On 04/04/15 21:30, Matthew Brush wrote:
On 15-04-04 03:45 PM, lmx wrote:
Hi guys,
I am running geany without problems for some years from now...
today i experienced a weird thing...
I decided to run vangrind against my code...
well...now i can't use gdb :(
I can compile and run the process, but not debug it...
when I try to open a file with fopen or use calloc, or malloc, the geany debuger trows me some erros :(
like this for malloc/calloc:
"Can't find a source file "/home/aurel32/eglibc/eglibc-2.17/malloc/malloc.c""
"home/aurel"??? why? wtf..
Another errors: when I try to access a FILE * pointer, for a regular file, that exists!
Can't find a source file "/home/aurel32/eglibc/eglibc-2.17/libio/iofgets.c"
I can't work...but I can compile??don't understand this...
for what I understand valgrind is controlling the binary file, and this process, is afther that "corrupted" right ??
but even then, deleting it, compiling again with gcc...running it ok, debuguing it...i can't.
some info from valgrind report fther running my code against it:
==9423== Invalid write of size 4 ==9423== at 0x4E87037: _IO_vfscanf (vfscanf.c:1857) ==9423== by 0x4E8EBC4: __isoc99_vsscanf (isoc99_vsscanf.c:43) ==9423== by 0x4E8EB46: __isoc99_sscanf (isoc99_sscanf.c:32) ==9423== by 0x40143B: file_to_holder (ihx.c:267) ==9423== by 0x400E59: ihx_read (ihx.c:130) ==9423== by 0x40159B: main (main.c:16) ==9423== Address 0x51df44d is 13 bytes inside a block of size 16 alloc'd ==9423== at 0x4C2B514: calloc (vg_replace_malloc.c:593) ==9423== by 0x4013E1: file_to_holder (ihx.c:261) ==9423== by 0x400E59: ihx_read (ihx.c:130) ==9423== by 0x40159B: main (main.c:16) ==9423==
why is geany looking for "/home/aurel32/eglibc/eglibc-2.17/malloc/malloc.c"" when a malloc intruction occurrs in the code???
does any one have any idea how to solve this?
Hi,
Geany doesn't have a debugger or Valgrind support, so I guess you are using one of the debugging plugins? I would try to clean build and get it running outside of Geany from the command line, after your build issues are sorted out
I am running geany with the gdb plugin debugger made by Alexander Petukhov, I think is the only plugin for gdb, i think?! I have runned valgrind outside of geany(in one terminal), but with geany opened...i don't know if geany stores any config data...
then I closed geany, opened it again later, continuing debugging my application...
for what I understand Valgrind uses the linux-vdso.so.1 concept to trace syscalls...which is what i was doing after-all with malloc, calloc and fopen, etc... I don't know if valgrind in the running process sets any ENV VAR, and maybe that var is used by geany plugin...i don't know.
but after running my code against valgrind with geany opened, closed geany, and after opened it again...i am unnable to debug in geany with the errors that I show before..
but i can use gcc and make, to compile and link against glibc, without anny issue or warning.
(ex. it looks like you're linking "eglibc" in your home directory rather than some system-wide C stdlib, maybe on purpose?), I bet it will work with any of the debugging plugins. Valgrind should be totally unrelated to any of this.
the eglibc is a version of a glibc type used in Debian, which will be replaced in debian 8 by the glibc version of gnu.In fact eglibc is a gnu version with some improvements..its the same thing..
I am not running glibc in my home dir...that is the problem...something that is messing with geany in some location..and makes it thinking that glibc is in another location...because of that geany cannot find the code from glibc, i think...and trows a error..
I checked the HOME, PATH end vars, and its ok. I have donne a ldd(on my app *parsers*) to check against what dinamic libraries is have been linked, and its ok :S
~/Desktop/geany/lypus_parser$*ldd parsers* linux-vdso.so.1 (0x00007fffec1fe000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f83ac1a6000) /lib64/ld-linux-x86-64.so.2 (0x00007f83ac584000)
like I said , i can compile and link, even in geany, but i can't debug with geany...
I removed the executable file , then I compiled again, linked, and its run fine in console, but when i debug...i have that problem :(
On 2015-04-04 6:55 PM, lmx wrote:
Hi Matthew,
thanks for the help :)
On 04/04/15 21:30, Matthew Brush wrote:
On 15-04-04 03:45 PM, lmx wrote:
Hi guys,
I am running geany without problems for some years from now...
today i experienced a weird thing...
I decided to run vangrind against my code...
well...now i can't use gdb :(
I can compile and run the process, but not debug it...
when I try to open a file with fopen or use calloc, or malloc, the geany debuger trows me some erros :(
like this for malloc/calloc:
"Can't find a source file "/home/aurel32/eglibc/eglibc-2.17/malloc/malloc.c""
"home/aurel"??? why? wtf..
Another errors: when I try to access a FILE * pointer, for a regular file, that exists!
Can't find a source file "/home/aurel32/eglibc/eglibc-2.17/libio/iofgets.c"
I can't work...but I can compile??don't understand this...
for what I understand valgrind is controlling the binary file, and this process, is afther that "corrupted" right ??
but even then, deleting it, compiling again with gcc...running it ok, debuguing it...i can't.
some info from valgrind report fther running my code against it:
==9423== Invalid write of size 4 ==9423== at 0x4E87037: _IO_vfscanf (vfscanf.c:1857) ==9423== by 0x4E8EBC4: __isoc99_vsscanf (isoc99_vsscanf.c:43) ==9423== by 0x4E8EB46: __isoc99_sscanf (isoc99_sscanf.c:32) ==9423== by 0x40143B: file_to_holder (ihx.c:267) ==9423== by 0x400E59: ihx_read (ihx.c:130) ==9423== by 0x40159B: main (main.c:16) ==9423== Address 0x51df44d is 13 bytes inside a block of size 16 alloc'd ==9423== at 0x4C2B514: calloc (vg_replace_malloc.c:593) ==9423== by 0x4013E1: file_to_holder (ihx.c:261) ==9423== by 0x400E59: ihx_read (ihx.c:130) ==9423== by 0x40159B: main (main.c:16) ==9423==
why is geany looking for "/home/aurel32/eglibc/eglibc-2.17/malloc/malloc.c"" when a malloc intruction occurrs in the code???
does any one have any idea how to solve this?
Hi,
Geany doesn't have a debugger or Valgrind support, so I guess you are using one of the debugging plugins? I would try to clean build and get it running outside of Geany from the command line, after your build issues are sorted out
I am running geany with the gdb plugin debugger made by Alexander Petukhov, I think is the only plugin for gdb, i think?! I have runned valgrind outside of geany(in one terminal), but with geany opened...i don't know if geany stores any config data...
There's at least 3 GDB plugins for Geany that I know of; GeanyGDB, Debugger, and Scope (Scope being the newest and most actively maintained, AFAIK).
then I closed geany, opened it again later, continuing debugging my application...
for what I understand Valgrind uses the linux-vdso.so.1 concept to trace syscalls...which is what i was doing after-all with malloc, calloc and fopen, etc... I don't know if valgrind in the running process sets any ENV VAR, and maybe that var is used by geany plugin...i don't know.
Me either.
but after running my code against valgrind with geany opened, closed geany, and after opened it again...i am unnable to debug in geany with the errors that I show before..
but i can use gcc and make, to compile and link against glibc, without anny issue or warning.
(ex. it looks like you're linking "eglibc" in your home directory rather than some system-wide C stdlib, maybe on purpose?), I bet it will work with any of the debugging plugins. Valgrind should be totally unrelated to any of this.
the eglibc is a version of a glibc type used in Debian, which will be replaced in debian 8 by the glibc version of gnu.In fact eglibc is a gnu version with some improvements..its the same thing..
I am not running glibc in my home dir...that is the problem...something that is messing with geany in some location..and makes it thinking that glibc is in another location...because of that geany cannot find the code from glibc, i think...and trows a error..
I'm not sure, but I think you might need to be linking to compatible stdlib as Geany and GTK+ and stuff, in case they use different allocators and stuff like that. Also I would assume the stdlib headers have to match the library linking to, but I'm no expert here.
Personally, I would try and rule out issues by just using the regular stdlib (and dev/symbol) packages from distro.
I checked the HOME, PATH end vars, and its ok. I have donne a ldd(on my app *parsers*) to check against what dinamic libraries is have been linked, and its ok :S
~/Desktop/geany/lypus_parser$*ldd parsers* linux-vdso.so.1 (0x00007fffec1fe000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f83ac1a6000) /lib64/ld-linux-x86-64.so.2 (0x00007f83ac584000)
like I said , i can compile and link, even in geany, but i can't debug with geany...
I removed the executable file , then I compiled again, linked, and its run fine in console, but when i debug...i have that problem :(
I'm not really sure what your problem is, maybe somebody else can help. You might try using the Scope plugin and see if it works better for you.
Good Luck, Matthew Brush
On 5 April 2015 at 05:45, lmx lmx1@sapo.pt wrote:
Hi guys,
I am running geany without problems for some years from now...
today i experienced a weird thing...
I decided to run vangrind against my code...
well...now i can't use gdb :(
I can compile and run the process, but not debug it...
when I try to open a file with fopen or use calloc, or malloc, the geany debuger trows me some erros :(
like this for malloc/calloc:
"Can't find a source file "/home/aurel32/eglibc/eglibc-2.17/malloc/malloc.c""
That looks like an error from gdb not from Geany.
IIUC valgrind replaces the system malloc with its own for instrumentation purposes.
So gdb is possibly trying to find the source file for the valgrind library, and not surprisingly not finding it.
What happens if you run the *same* executable under gdb (doing the same thing, ie stepping into the same code) from the command line?
Cheers Lex
"home/aurel"??? why? wtf..
Another errors: when I try to access a FILE * pointer, for a regular file, that exists!
Can't find a source file "/home/aurel32/eglibc/eglibc-2.17/libio/iofgets.c"
I can't work...but I can compile??don't understand this...
for what I understand valgrind is controlling the binary file, and this process, is afther that "corrupted" right ??
but even then, deleting it, compiling again with gcc...running it ok, debuguing it...i can't.
some info from valgrind report fther running my code against it:
==9423== Invalid write of size 4 ==9423== at 0x4E87037: _IO_vfscanf (vfscanf.c:1857) ==9423== by 0x4E8EBC4: __isoc99_vsscanf (isoc99_vsscanf.c:43) ==9423== by 0x4E8EB46: __isoc99_sscanf (isoc99_sscanf.c:32) ==9423== by 0x40143B: file_to_holder (ihx.c:267) ==9423== by 0x400E59: ihx_read (ihx.c:130) ==9423== by 0x40159B: main (main.c:16) ==9423== Address 0x51df44d is 13 bytes inside a block of size 16 alloc'd ==9423== at 0x4C2B514: calloc (vg_replace_malloc.c:593) ==9423== by 0x4013E1: file_to_holder (ihx.c:261) ==9423== by 0x400E59: ihx_read (ihx.c:130) ==9423== by 0x40159B: main (main.c:16) ==9423==
why is geany looking for "/home/aurel32/eglibc/eglibc-2.17/malloc/malloc.c"" when a malloc intruction occurrs in the code???
does any one have any idea how to solve this?
thanks in advance
regards tux _______________________________________________ Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Le 29/03/2015 00:23, Thomas Martitz a écrit :
[…]
- linkage-cleanup (PR#429) - This changes the way plugins access Geany
API functions. Instead of exporting a pointer to a struct of structs of API function pointers, now the APIs are exported directly. This work also includes an effort to stop exporting all function (we do this currently as a workaround to allow gtkbuilder to work), so *only* API function are exported and plugins cannot call internal function anymore. This change is also required to allow gobject-introspection to find geany functions at runtime (through g_module_symbol()) in the future.
Agreed, but on the fact that it's not actually "also required for GI", it's *only* required for this kind of thing. It's good and everything, but not required but for dynamically looking up the functions.
- new API functions for registering keybindings (PR#376). The current
API functions do not allow context information to be stored and passed to the key handler function. This makes it very hard for non-C plugins to use these function. So what's needed are key handlers that get the necessary context information. This allows interprepted language plugins to register keybindings.
Agreed.
- A new plugin loader mechanism (a thread about this is already running
on the devel list): Similarly to the keybindings, the plugin_* functions implemented by plugins do not carry any context information, making it hard for non-C plugins to implement them properly. Therefore a new loader mechaism is needed so that the context information can be passed. The loader works such that an API function is called to register a function pointer table. This is crucial to possibly support plugins that register other plugins (so called pluxies) which is simply not possible with the current mechaism. The current loader is kept for backwards compatibility (but will not receive new features).
Agreed.
- New API functions to allow plugins to act as proxy plugins (pluxies).
These pluxies can then implement whatever is needed to execute code in the in the actual plugin, like invoking an interpreter or firing up a java vm. The pluxies call the new loader's API function on behalf of the actual plugin. The API function to implement the pluxies is a simple geany_register_pluxy() that, much like the normal plugin loader, that pluxies use to pass a function pointer table which implements the necessary hooks (probe(), load() and unload())
That's the part I'm really fuzzy about. I really don't see why we need this specific layer (maybe in an ideal world not bothering about how Geany currently does it): as asked on the other thread, why do we need anything beside geany_plugin_register() (required for everyone) and geany_plugin_unregister() (required only when registered sub-plugins, as the parent need to clean them up when it itself quits)?
Regards, Colomban