I am actually working on issue/feature request https://github.com/geany/geany-plugins/issues/733.
I extended the workbench plugin and now it allows to create global and projects commands, to store the values in the projects and workbench file and to inherit global workbench commands to the projects. This are all workbench internal functions.
When it comes to actually execute a command I planned to use ```build_set_menu_item()```, ```build_activate_menu_item()``` and to introduce a new build source called ```GEANY_BCS_PLUGIN```. But just adding a new build source is not doing the job. I guess ```build_activate_menu_item()``` is simply ignoring a new value.
Also, the workbench plugin maintains several projects and that would mean to re-write the commands each time by calling ```build_activate_menu_item()```. And the functions doesn't seem to free old values by itself.
I came to the conclusion that for my approach (and maybe for other plugins) it might be more suitable to have a direct plugin call like ``` build_execute_command(BUILD_TARGET_COMPILER, command, workingdir); ``` The first parameter given should tell if the command output goes to the "Compiler" message window. An alternative value would be BUILD_TARGET_NEW_TERMINAL which means start a terminal and run the command in it. This seems to be what the groups ```GEANY_GBG_FT``` /```GEANY_GBG_NON_FT``` and ```GEANY_GBG_EXEC``` do today.
The API call should work in a Fire&Forget manner: parameters ```command``` and ```workingdir``` should be copied (if necessary). Then run the command as described above and once finished simply forget about ```command``` and ```workingdir```.
What do you think?
When it comes to actually execute a command I planned to use build_set_menu_item(), build_activate_menu_item() and to introduce a new build source called GEANY_BCS_PLUGIN. But just adding a new build source is not doing the job. I guess build_activate_menu_item() is simply ignoring a new value.
Yeah, you have to program everything that gets commands to know about it, the overloading order isn't straightforward, so its explicitly programmed, so a new source needs to be programmed in too, see for example `get_next_build_cmd()`. You also need to allocate the command array somewhere.
Also, the workbench plugin maintains several projects and that would mean to re-write the commands each time by calling build_activate_menu_item(). And the functions doesn't seem to free old values by itself.
I presume you mean `build_set_menu_item()` and there the `SETPTR()` macro does the free.
The first parameter given should tell if the command output goes to the "Compiler" message window. An alternative value would be BUILD_TARGET_NEW_TERMINAL which means start a terminal and run the command in it. This seems to be what the groups GEANY_GBG_FT /GEANY_GBG_NON_FT and GEANY_GBG_EXEC do today.
Well those groups do rather more than that, especially execute which makes the script and then runs the command without monitoring its stdout and stderr.
The API call should work in a Fire&Forget manner: parameters command and workingdir should be copied (if necessary). Then run the command as described above and once finished simply forget about command and workingdir.
It can't be fire&forget since it has to monitor the command and restore the menu sensitivity when it finishes. If you want fire and forget maybe you would be best to spawn the command yourself, though that would mean doing your own replacements. I'm not sure where they are used, but the build info structure stores the group and index while the command is running, so a command without those may be difficult to integrate.
When the build command system was upgraded to the current cascading overload system, one of the devs objected to it and did not want to make it visible to plugins because he wanted to change it. So the doxygen comments were disabled by adding a space between the `**`. That dev is now inactive and, over time, because people have needed access to the build system from plugins, some parts have been made visible in a somewhat ad-hoc manner. You can still see some disabled doxygen comments in build.h and build.c.
Probably the whole visibility of the build API could be revisited, for example if `GeanyBuildCommand` was available to plugins then they could manage the plugin source array themselves and so could set its size themselves. The Geany arrays are set at startup only from values in the config, and that wouldn't be terribly convenient to plugins.
I presume you mean build_set_menu_item() and there the SETPTR() macro does the free.
Thanks, forgot to check the macro.
It can't be fire&forget since it has to monitor the command and restore the menu sensitivity when it finishes.
Sorry, I wasn't very precise. I meant fire&forget from the plugins perspective. It's logical that some kind of state information needs to be managed for the execution time of a command.
Yeah, you have to program everything that gets commands to know about it, the overloading order isn't straightforward, so its explicitly programmed, so a new source needs to be programmed in too, see for example get_next_build_cmd(). You also need to allocate the command array somewhere.
Hmmm...OK. Thought I could prevent that :-) I don't really like the close relationship of the build command GUI to the job/service of command execution. I guess I can only reserve some fixed memory for the ```GEANY_BCS_PLUGIN``` arrays at init time so that values can be filled in.
Probably the whole visibility of the build API could be revisited, for example if GeanyBuildCommand was available to plugins then they could manage the plugin source array themselves and so could set its size themselves. The Geany arrays are set at startup only from values in the config, and that wouldn't be terribly convenient to plugins.
Yes, I have implemented my own method for passing on global workbench commands to the single projects which simply works on the labels, not on the index/position. I only use the index/position of a command for the position in the popup menu. But the number of commands is not fixed. This doesn't fit to good to the current mechanism but I like it. I guess it is not very likely that the whole thing is being re-written so I maybe just let the user choose/enter a mapping to a build menu position.
github-comments@lists.geany.org