On 11 February 2010 00:01, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Sat, 6 Feb 2010 16:40:57 +0100 Enrico Tröger enrico.troeger@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@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel