[Geany-devel] Build system branch 2.0

[Lex Trotman]

On 11 February 2010 00:01, Nick Treleaven <nick.treleaven at btinternet.com> wrote:
> On Sat, 6 Feb 2010 16:40:57 +0100
> Enrico Tröger <enrico.troeger at uvena.de> wrote:
>
>> IMO way too much information.
>> I already said that about the current build settings in the SVN version
>> and this one is even worse, IMHO. Yes, for users who want the ultimate
>> control of every single build option that could be useful but, as also
>> said multiple times before, the idea of Geany's build system was to be
>> easy to use and to just get the job done. From my experience, this was
>> much appreciated by users (getting lots of mail stating this). Well,
>> this feature we will loose with the current rework in the SVN version
>> and with the mockup in the new branch, it won't get better, IMHO.
>>
>> Sorry when this sounds a bit hard and I do understand your motivation
>> to make it all more flexible. But it's maybe just not want
>> some/most/all users want.
>
> I agree, I don't like this design, sorry Lex ;-)

Hey, thats what I made a python prototype for, so no sorry needed.

>
> I think making all functionality available is overkill. We've got to
> come up with a design that makes sense for each set of commands.

Yes, but hard coding such restrictions increases the complications of
the code (those special cases) and then forces users who need
something else to change code not just configure.  Including having to
change existing special cases (or to ask you to change it).  There
should be much less work to create and maintain a good general
solution.

>
> For example, you can only have one build command stopable, unless you
> make new build tabs in the message window. I think this is too complex.

Agree that there should be only one output to the message window, and
I have already written that in the spec. (I like the tabbed idea,
maybe Geany version 3.0 :-)  But the dialog wouldn't show that, its a
function of the menu operation.  When a parsed command is run, all the
other parsed menu items become insensitive.

For stopability, (if thats a word) the decision which command is
stopable has to be made at the time a menu item is selected, the one
thats selected becomes stopable, the other parsed menu items become
insensitive.

But there are some build commands that should NOT be stopable, ever,
because of the risk of corruption ( see past discussions with Thomas
and Enrico), so stopability needs to be able to be turned off for
them, and since in general we don't know what commands are running, it
has to be off by default.

>
> Any increase in functionality needs to have a rationale. Do we need
> each command to be handled individually, or should sets of commands
> have the same behaviour? I prefer the latter.

Yes thats a reasonable way to do it, but what are the groups and what
are their characteristics.  I couldn't come up with a sensible set of
fixed groupings that don't unreasonably limit the behaviour.

The current SVN version basically works like that and I can't twist it
to support the build commands that I want to use, let alone what other
people may need.  For example Frank & Thomas both have asked for
executes without terminal or parsing. The current SVN can't support
that without one more setting being added and then the next variant
has to be added etc. and soon it gets to where I am at now.

So I gave up and made everything settable :-) no special cases or
inconsistent operation :-)  but as you and Enrico say, making the
configuration GUI approachable is a problem :-(

It would be possible to have a separate dialog to define new groups
and their characteristics so all that needs to be set in the main
configuration dialog is the group name from a combo box.

The advanced dialog would only have 6 characteristics to set, or
actually only 4 when you consider some are just an enable for the
following value.

Default groups and their characteristics:

- Internal - internal and which internal item
- Parsed - parsed, not stopable, regex
- Execute - to terminal, stopable, stop label "Stop"
- Execute no terminal - no terminal, stopable, stop label "Stop"

 Lets see what that can do for us.

Cheers
Lex

>
> Regards,
> Nick
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>