> 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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1897#issuecomment-405353489
