Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Allowing Plugin Interdependency and Improving Plugin Management
dmoore:
--- Quote from: oBFusCATed on November 11, 2013, 09:09:43 am ---Hm, I think I'm being misunderstood. I don't like the idea of having plugins for plugins, I'm relatively ok with the idea of plugin communications.
So, lets stop arguing and just do it if you need it.
--- End quote ---
Yes, clearly we are talking past each other. :) The reason I haven't just "done it" is I am still not sure of the best way to proceed.
The bottom line is that I want to scratch two immediate itches:
1. I had at one time developed a Python Interpreter "console" that would appear in the tools plus dockable and I want to get it working again, but now that Tools+ is part of contrib this is a pain. If I moved the relevant bits of Tools+ into the core, then I just need to expose these bits in the SDK API. Alternatively, I need to figure out some other way for the python interpreter to use that notepage (either (a) link against Tools+ itself or (b) have Tools+ and the Python Interpreter links against a common shared lib a la wxSmith).
2. The rest of my python programs uses some XMLRPC stuff that I want to share across plugins. The common bits take care of all the messy process management and threaded communication using a manager class that there really should only be one of. So again, I either need a shared library approach, a link against plugins approach, or I could do the multiple plugins in a single binary as you propose below.
--- Quote ---Have you though of putting all of your python subplugins in a single binary? I think this is possible already in C::B and probably will be easier for the user. :)
--- End quote ---
This isn't a horrible idea. BUT... Do any of our current plugins do this already? I ask because as far as I can tell the PluginManager code doesn't really handle all of the nuances involved in this. e.g. has anyone tried to uninstall or export one of these plugins?
My patch will need to be modified to handle this case as well. e.g. I unload after detaching a plugin, but I should only unload after the last plugin in the bundle has been disabled.
thomas:
(note: I've only read the first 5 posts)
I find the idea great in general, but it would need to be done with thought and care. Even if it turns out to be really easy, please spend another month or so thinking about it. The reason is that we can't change the way plugins work every few weeks (or we'll get abuse both from plugin writers and from users who have broken setups), so whatever we do, it will be "The Way Plugins Are" for the next couple of months/years. Think twice, then think again. Other than that, great plan.
As for linking one DLL (a plugin is just a DLL after all) against another DLL under Windows, this is something I've done many times in the past, without doing anything special (I heard of the visibility flag for the fist time too :P). Are you sure it's problematic? I think it might just work fine.
oBFusCATed:
--- Quote from: thomas on November 11, 2013, 06:56:25 pm ---As for linking one DLL (a plugin is just a DLL after all) against another DLL under Windows, this is something I've done many times in the past, without doing anything special (I heard of the visibility flag for the fist time too :P). Are you sure it's problematic? I think it might just work fine.
--- End quote ---
dmoore's problem is that he doesn't want to place his so/dll file next to libcodeblocks.so/dll, but this is a requirement at the moment (I've not checked if this is really the case, but I suppose it is).
The visibility flag is something unrelated to this problem. What it will do is to change the defaults to be a bit more sane, aka windows like. This is something that will happen in the future, when I find the time to do it.
dmoore: I've never tried to place two plugins in a single binary, but I've thought it is supported... but I might be wrong.
dmoore:
--- Quote from: thomas on November 11, 2013, 06:56:25 pm ---please spend another month or so thinking about it.
--- End quote ---
Roger that.
--- Quote ---As for linking one DLL (a plugin is just a DLL after all) against another DLL under Windows, this is something I've done many times in the past, without doing anything special (I heard of the visibility flag for the fist time too :P). Are you sure it's problematic? I think it might just work fine.
--- End quote ---
On windows it should be straightforward because we can add the plugin dirs (user and builtin) to the library path at runtime. On linux, We can use -rpath to add say /usr/lib/codeblocks/plugins, but I haven't figured out how to add the plugin dir in the users home. It's almost as if the GCC devs think that's a security risk ;D
oBFusCATed:
--- Quote from: dmoore on November 12, 2013, 03:05:25 pm ---It's almost as if the GCC devs think that's a security risk ;D
--- End quote ---
GCC devs have nothing to do here. Its the dynamic linker devs (glibc) that think this way.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version