I would like to know if there is a function which a plugin can call to query if a keybinding/key press combination is already in use (by geany itself or a different plugin).
Ideally this would return displayable information about the assigned action like in the keybindings preferences dialog.
Is there any function for this? Or do I need to search through the ```keybinding_groups``` array myself?
No such function.
Checking for keys already in use is part of the prefs keybinding dialog functionality, so it gets done for your plugins keybindings when the user modifies them and the plugin doesn't have to care.
Thanks, I know that the keybinding dialog is doing that. But that has to be done manually by the user.
I was thinking about writing a plugin which could be called a "keybinding wizard". By itself it should do nothing. Instead it should offer an API to other plugins. Other plugins could pass over a list of keybindings they would like to use. Then a dialog could open which only applies these keybindings. But of course that dialog needs to check for existing keybindings and let the user decide to overwrite an existing keybinding or not.
This e.g. could be used by the scope debugger plugin to setup a keybinding wizard that let's the user easily set the keybindings of other debugger GUI's rather than hacking them in one by one (of course the list of keybindings would need to coded into the scope plugin but it wouldn't need to write the wizard dialog itself and the dialog/wizard functionality could also be used by other plugins).
What do you think about that?
Managing resources shared between plugins (keybindings, markers, etc) is an acknowledged issue that hasn't been solved so far. Thats why its recommended that plugins do not set keybindings by default, leave it to the user to de-conflict, they are hopefully smarter than plugins :)
On a practical note, the order that plugins are loaded is undefined, and the user can select to not load a plugin at all, so plugins can't rely on other plugins since they may not be loaded at the time they are needed.
Better would be to try (again) to get a more general solution to the shared resource problem, or at least keybindings, built into Geany.
Well, I do not mean by default. The user would still need to do an action like selecting a menu item to open the wizard. But I understand that the plugin dependency is a problem.
Would it be acceptable to build such a little wizard-API into geany or would a PR for such a wizard be rejected?
Would it be acceptable to build such a little wizard-API into geany or would a PR for such a wizard be rejected?
I am not sure what you actually want it to do so can't say.
I think you need to describe the use-case and your proposed solution in more detail _before you do any coding_ to see what the general feeling is, describe what the intended functionality is, how it would work etc.
Note in general Geany does not (and should not) know anything about individual plugins, any information Geany needs to do the job has to be communicated from the plugins. That also means whatever you propose should be general and work for all plugins, not just debug plugins you mentioned.
@LarsGit223 this sounds like a good use-case for a regular shared library. Any plugins who would like to use it could just link to it, and it could be added to the Geany-Plugins build system if needed.
@codebrainz: if I understand you right you mean a simple library which is NOT making use of the plugin interface. Wouldn't such a library then always be needed to be linked/installed? Even if no plugin is using it?
@LarsGit223 the library could make use of the plugin API. It would just contain the shared code that multiple plugins would want to use. This just puts the burden of dependencies on the OS runtime linker instead of Geany's simplistic plugin loader.
I think I was unprecise. I meant the library would NOT register itself as a plugin, right?
How intelligent is the runtime linker? I guess it simply links together every function that is in use. I mean if a plugin would use a function of my library then the function would be linked in even if the plugin is not activated.
I meant the library would NOT register itself as a plugin, right?
Correct, it would simply link against `libgeany.so` to gain access to the plugin API.
How intelligent is the runtime linker? I guess it simply links together every function that is in use. I mean if a plugin would use a function of my library then the function would be linked in even if the plugin is not activated.
When Geany loads a plugin using your library, the library would be loaded by the runtime linker, the same as any other library. For example if Webhelper and Markdown are both linked against the same WebkitGtk version, only one copy of that library would be loaded into the process. If both Webhelper and Markdown plugins are de-activated, the WebKitGtk library would be unloaded, barring the use of certain libdl flags such as `RTLD_NODELETE`, perhaps.
An ASCII art representation:
``` +-----+ | GTK | +-----+ ^ | +-------+ +----------+ +----------+ +-----------+ | Geany |------------>| LibGeany |<---| Your Lib | | Other Lib | +-------+ +----------+ +----------+ +-----------+ ^ ^ ^ +----------+ | | | | Plugin A |---------------+ | | +----------+ | | | | | | +----------+ | | | | Plugin B |---------------+----------------+ | +----------+ | | | | | | +----------+ | | | | Plugin C |---------------+----------------+---------------+ +----------+ ```
"Plugin A", "Plugin B" and "Plugin C" depend on "LibGeany" as every plugin does. "Plugin B" and "Plugin C" also depend on your "Your Lib" (which itself depends on "LibGeany"). "Plugin C" additionally depends on some "Other Lib" unrelated to Geany/Gtk.
Ok, sounds like the simplest solution. I do not know when I will implement the keybinding wizard.
Apart from that it should be considered to plan a common lib anyway. So plugin developers can move common code there. If there is no possibility to do it, then no one will start preventing this kind of code duplication. E.g. some code of the project organizer plugin and my workbench plugin is quite the same and could eventually be shared in a lib.
@LarsGit223 it's a chicken vs egg scenario. Until somebody has a need for such shared code, nobody's going to integrate that into Geany-Plugins. Making an empty library would be rather pointless. If you feel like extracting some shared code, I could probably assist in integrating it into the build system, though I don't understand the way Geany-Plugins uses Autotools very well (lots of custom macros).
@LarsGit223 note also that plugins are created and maintained by different people, they may not _want_ to share code. So you will have to address the social as well as technical issues.
Meh, one thing all developers can agree on is DRY :)
So who controls the shared library, one thing programmers don't agree on is which way libraries should/should not evolve eg Gnome vs the rest of GTK users.
The same people who maintain Geany and Geany-Plugins (ie. contributors). It's not some general purpose 3rd party library like GTK, it would be inside GP repository for the specific purpose of providing shared functionality needed by plugins and maintained by plugin developers and other contributors.
I agree to both of you.
@elextr: of course everything should be on an voluntary basis. If a developer does not want to share the code then ok we have to accept it. It might also be a matter of time to write code in that way that it can be commonly used. But also like @codebrainz mentioned I would expect that most developers have a natural need to prevent code duplication and also to use existing code if already available.
So hopefully, once started, it would grow with the time.
@codebrainz: yes, I also see it as a common lib specific to geany plugins. Not comparable to general purpose libs like glib or gtk.
As a start I could try to move the directory scanning code of the workbench plugin into such a lib. I think scanning directories for files based on a pattern could be useful for other plugins to.
I guess we should create a branch for this. So I can move the code there and who ever knows the build system best can write the make code to build the lib.
@LarsGit223 you could just create a branch on your fork, probably make a PR for visibility. Anyone can make a PR to your fork to integrate changes into the main PR.
I think my question is answered and so I close this now.
Closed #619.
github-comments@lists.geany.org