> If we want to add plugins to be a build command source we would need to > define a new GeanyBuildSource, e.g. GEANY_BCS_PLUGIN.
Correct > So e.g. exec_proj holds the commands for the prjoject and does not point to > one command but to an array of 9 commands (maximum?). It points to the project commands for the execute section of the menu correct. Not sure its limited to 9, but whatever the number is, its set at startup and can't be changed without restarting Geany, and the defaults are only 3/4/2 for filetype, non-filetype and execute sections. Remember the bigger you make the numbers the bigger the `Set Build Commands` dialog gets, but the menu only shows commands that are not empty. > For the case that there is more than one active plugin wanting to be a > GeanyBuildSource I wonder if it wouldn't be better to call a function which > is doing the decision for the plugins and returns the list of commands that > won. Note that there are already build access functions in the plugin [API](https://www.geany.org/manual/reference/build_8h.html), plugins shouldn't be accessing the Geany internal structures. But the existing functions make no decisions what the plugin can do, and I repeat my question from previous posts, how does Geany decide who won? As @codebrainz pointed out, for markers Geany can allocate them since there is more than one marker, so until exhaustion Geany just provides the first free. But for build commands, each command slot only holds one command, so one of the plugins will naturally "win" the slot and no other plugin can use it. > Also if I understood it correctly the build dialog can be re-used as it saves > the set commands into dst which in this case would need to point to the > memory area for the workbench plugin (using function GtkWidget > *build_commands_table(GeanyDocument *doc, GeanyBuildSource dst, > BuildTableData *table_data, GeanyFiletype *ft). You mean the `Set Build Commands` dialog I guess. My thought was that plugin commands NOT be set there, just shown as insensitive since they are the highest priority. For example lets say you added `%w` as the Wonder Workbench substitution. You need to do that before the command is used by Geany since Geany doesn't know how to substitute it, so if the user is entering the %w in the Geany dialog, then when a command was about to be run you would have to re-write the command with the substitution done, then wait for Geany to run the command, then replace the original for the user to edit (or something similar). Easier for the user to edit it in a Workbench dialog and you just write the version you want run in the Geany slot and update it when whatever controls the Wonder Workbench substitution changes. And thats why I suggested that Geany would not save plugin commands, the plugin would be saving the original unsubstituted version. Also for @codebrainz temporarily languishing Clanglib plugin, the commands might be created in some complex algorithm to handle all the include paths and options and stuff, not just be simple substitutions. By having the user edit it in the plugins dialog you can reinforce that they can (or must) use the plugin specific features. > So what about exposing only one pointer, e,g, GeanyBuildCommand *exec_plugins > = NULL; to geany-plugins and call some function which is doing the work of > return_cmd_if for the plugins? These pointers are not and should not be exposed, they are Geany implementation details. Thats another reason not to have the user edit plugin commands in the Geany dialog. > And as @elextr suggested put some registration/priority handling/arm > wrestling code to the shared utils lib in geany-plugins. Yes, then that can do whatever algorithm plugins agree to use, eg Workbench always wins :grin: -- 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-plugins/issues/733#issuecomment-380976609
