2009/7/13 Thomas Martitz thomas.martitz@student.htw-berlin.de
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.
Nasty is a bit harsh, but I agree its only a workaround. BTW I'm not disagreeing about the need for some improvement in the area of directory management, see below (sorry Enrico, another 'short' email)
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?
I'm glad, the announcement has a list of what I know I still need to do, some of which changes build.c quite a bit.
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.
Agree see below.
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.
Oh yes, It must have been made out of the branch, the trunk build.c is VERY different, this build.c is a significant re-write. The problem most likely is that there are still significant things being done to build.c to reduce the list of known bugs, limits and incompletes.
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
At the moment the directory handling is the same as Geany 0.17. This was as agreed when the scope of the changes were discussed in this ML.
But lets think some more about the problem of where commands run and how best to provide flexibility and ease of use. There are three groups of commands and several sources that need to be considered.
Filetype commands are intended to be run on the currently open file, so they always run in the source file directory. This allows them to be used for simple single file work without configuration, and allows movement around more complex source trees, again without configuration. Whilst there may be a use case for configuration to a fixed directory that I can't think of, I am sure that it is likely to cause confusion when a file in another directory is accidently used. Therefore I believe that the current behavior is correct.
Non-filetype commands are a bit more complicated. Since this group is intended to run commands independent of the source file, in theory it could be any directory, But there are a couple of likely candidates: - for make type builders to build the entire package the top of the tree is the right place, that is a fixed directory (at least for each package it is) - for make type bulders that build lower levels than the whole package, then somewhere below the top of the tree is right, that isn't a fixed directory (an example of where you use this is make doc in geany's doc subdirectory)
The current behaviour of Geany is to provide an approximation of both, at least if you are using a project. A fixed directory for all commands for this package is provided by the base_dir of the project, otherwise the directory of the current file is used as the most likely place to run commands within the tree. (Note although it is called the project base directory, I am not aware of any reason why it can't be set to any arbitary directory no matter where you keep the project file. So you can set it to a subtree if you intend to work there for a while) The make in base dir checkbox allows each command to be directed to one of these options.
Allowing each command to be run in a specific directory would add flexibility, but I for one wouldn't want to have to configure each command for each project, so the run in base should still be provided as a common setting and I can't think of a better analogue of the subtree than the directory of the current file, unless a select directory dialog is used (not suggesting it for now, but it could be a future). Therefore when a project is open each command needs to select between three possible directories, base, current or set in the dialog. Set in dialog could be selected if the setting is non-blank but we still need the base_dir checkbox as well. Or maybe a dropdown list to allow for the inevitable expansion ;-).
At the last minute I have also thought of another option that I would find useful, that is to have an option for the base_dir to be relative to the project file so that the whole tree can be copied around without having to re-configure the project file. So a project file with appropriate command settings could be included in version control and checked out with the tree.
When running without a project there is no base_dir available, so Geany runs commands in the directory of the current file or not at all. This could be improved by having a preference for a common directory (a base_dir for non-project use) and by having per-command directories.
I'm not entirely satisfied by this approach since I usually have multiple things on the go at once, and having to change the configured directory each time I change what I'm working on is not nice (but at least with the common one I would only have to change it in one spot). So maybe a popup to ask for the directory, that remembers the current value (so running a make the same as the last is just shift+f9 return) and has past values in a dropdown, might be needed sooner than I implied above.
Anyway thats my thoughts for now, lets see what the Geany community thinks, feedback encouraged.
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel