> 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 

1. Load and save build command data for a plugin (of course a job for the 
1. 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```.
1. 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)
1. 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 :thumbsup:

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:

Reply via email to