On 16 February 2010 03:09, Nick Treleaven
<nick.treleaven@btinternet.com> wrote:
On Mon, 15 Feb 2010 13:02:05 +0000
> > Since any command can be run by the build menu, it can be a long-running
> > command, so why not allow a competent user to decide that it is safe to stop
> > it if its going wrong?
Sorry, my comment about execute commands was not in reply to the
above, only about commands that you don't want to be parsed in the
Compiler tab.
Understand.
For the stop issue, I don't think a dialog is that bad. How often do
you need to stop things?
Usually not for weeks then several times in a row ;-)
You could still have a pref, on by default,
for whether to ask/warn the user first or not.
What ANOTHER setting? :-D HeHe, sorry I couldn't resist....
I would prefer for each new 'feature' like stopability or concurrent
commands or whatever to be discussed separately, otherwise it's
difficult to find the best solution. You're saying look at all these
things people might want from the build system, hence a big and
complicated configuration dialog is necessary. I'd prefer to look at it
from where we are, what is needed incrementally.
I don't really agree, I'm aware that the dialog is a problem, I may not have been clear but I'm talking only about the internal implementation here.
All of the functionality I am proposing exists in the SVN version, sensitivity of parsed commands, stopability (without dialog) etc, but which menu items each piece of functionality applies to is hard coded. I am a lazy programmer, I want to have only one type of menu item and let configuration control its functionality. That is simpler than having the same functionality controlled by lots of hard coded nested ifs as it is in the SVN version.
Then, as I said in reply to Enrico, the configuration and the default configure dialog can hide as much or as little of the functionality as you want. That will take some talking about... ;-)
And the complex full configuration dialog could be a plugin.
Cheers
Lex