[Geany-devel] ANN: Configurable Build Menu Alpha in SVN

[Lex Trotman]

2009/7/13 Thomas Martitz <thomas.martitz at 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 at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20090713/20da7c1c/attachment.html>