> Perhaps it would be better for you to just reimplement it in workbench for
> your purposes and maybe at some point in the future you can make a simpler PR
> to disable Geanys features so only yours are available, if you think having
> both will confuse users.
Hmmm...I think not because I do
- any caller can create it's own source
- it should have a name so we do not get linker issues (meaning it should be
dynamic)
- the caller can specify at which position to insert his source in the sources
cascade (by name, e.g. before "project")
- the cascade of build sources could be
@elextr: thanks for the response, better late than never :grin:
Actually I stopped working on this for two reasons:
- the Geany code is not easy to extend
- it would make more sense to put the workbench plugin in the cascade before
the project so that projects can inherit workbench global build
@pztrn: you wrote
> I'm using Geany while writing Go code and it's vital to have some commands
> (like golint and gofmt) to be launched periodically.
Apart from having some workbench global settings can't your problem be solved
by using filetype specific settings? It should be possible to set
> 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.
I don't recommend re-using the Geany GUI implementation, that was created a
long time ago. It handles the fact that
> 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
> 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
I had a look at the code in ```build.c``` and tried to understand what it's
doing. This is how I understood it:
If someone (a plugin) wants to re-write the build menu it would have to call
```build_menu_update``` and then the menu items are re-written according to the
magic/selection process
> From previous discussions, I think the suggestion (consensus?) was that for
> resources like markers, indicators and such, it would be best for Geany to
> manage and allocate these for the plugins so that each plugin doesn't try and
> use the same indices.
Yes, and thats what I argued in the
>From previous discussions, I think the suggestion (consensus?) was that for
>resources like markers, indicators and such, it would be best for Geany to
>manage and allocate these for the plugins so that each plugin doesn't try and
>use the same indices.
>From the filetype plugin discussions,
@LarsGit223 yes thats exactly what I mean.
> If there is more than one plugin, what do we do?
Probably the same as when two plugins share any resources now, fail in
unpredictable ways. This already occurs when you run two plugins that both use
markers (bookmarks is one, not sure of the
@elextr: thanks for the pointer. So we would need to extend the list like below
1. default settings coded in Geany
1. settings in the system, that is the installed filetype file for the type of
file selected in the editor
1. settings from the user preferences file
1. settings from a user
PS see [this](https://wiki.geany.org/howtos/configurebuildmenu) for how the
system works and what a "source" is.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
What the build system really needs is another source for plugins to use, but
which would not be saved by Geany. Then plugins can inject any command having
performed any transforms on them. At the moment a plugin has to remember to
put the Geany command back if it sets its own, or that command
As I am also using Geany for C development myself I have the same goal to be
able to set some project settings using the workbench plugin. But this will be
a long term goal and not happen in the near future I think.
Also, I still have to make up my mind how it is done best. In C the build
15 matches
Mail list logo
