Lex Trotman schrieb:
Hi Thomas,
Thanks for looking at it and working on improvements already.
(below copied from your previous email so I can reply to both at once)
Great work! That's a thing I'm really missing for Geany.
I'm digging in a bit. The dialog looks good already, but I think it
lacks a important field:
Working directory for the command.
To run a command in a specific directory just make the command field "cd <the directory>; <the rest of the command>"
I figured that it works. But that's overly nasty, especially with regards to multi-plattform support. Working dir of a process/command is a very basic and essential thing.
That seems to be what your code is trying to do through a field for the directory, if I have misunderstood please explain.
Yes, that's correct.
If that is the case then I don't feel there is a need for another field in the dialog or any express support in the code, anyway for now my concern is getting the basic functionality working reliably and getting it used.
What doesn't work "in a basic way"? I'm using it right now and works mostly?
It should be obvious, that for many projects, the source files are
structured,
so that having the working dir default to the dir where the source
file is located doesn't work.
And the base directory of a project also doesn't always work.
True, this is just replicating the current way Geany performs so that it can load old config files.
I'm looking at the code in the hope I can add it. It's a bit hard
for me to read the code,
it lacks comments and structure here and there, but I hope I'll find
my way.
Yeah, thats the way of code thats evolved from an experiment through several iterations (15 according to my local version control) I intend to improve things when its all working.
No problem. Documentation and readable code is essential at some point, though.
I don't understand why it needs to be a loop like that, just add another field to GeanyBuildCommand and use it where you need to. Much easier to understand for simple folk like me ;-) Then all other places addressing label and command don't need to change.
Because code duplication is bad, ugly and very error prone. And in most places, the code applies to all GtkEntry fields from the settings. The code isn't readable worse due to usage of the enum (.entries[BC_COMMAND] is as obvious as .command). It's needed almost everywhere were label and command are already needed (such as for config loading or dialog ui handling)
I tried to apply your patch to my working copy but 25 out of 27 chunks were rejected, thats the problem with patches on a rapidly changing source.
The patch is made off the branch, I'm fairly sure (going by the IRC bot) that there hasn't been much commits in the meantime.
So the patch can't be used directly, and for now I can't spare the time to work out the problems since there are still important bits of functionality to fix/add, but if the method of setting directory suggested above isn't sufficient let me know.
Cheers Lex