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.

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.

By re-using it, I meant using only the GUI. I thought it would write the settings made by the user to dst so that it would not change any other data that belongs to geany.

Note that there are already build access functions in the plugin API, 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?

I still need to look at those. Right now I am not sure which tasks can be done where and how we can limit code duplication. I think these are the three main tasks:

1. Load and save build command data for a plugin (of course a job for the plugin)
2. Having a GUI dialog to edit these settings (as written above I thought the existing geany dialog could be re-used WITHOUT changing any of the geany data - I want to pass over the pointer for the workbench data as dst.
3. A menu for the user to start the build commands (I thought extension of the six sources with a seventh for plugins meant to re-use this because it would decide which command to run)
4. Having code that actually runs a build command (also done through the above I thought)

If a plugin or plugins has it's own complete build menu and set build commands dialog, then there wouldn't be any interaction with geany? So are you talking about to duplicate that code for the plugins?

Anyway, still have to look at the existing API functions. Thanks for the detailed answer 👍

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.