On 16 February 2010 03:09, Nick Treleaven nick.treleaven@btinternet.comwrote:
On Mon, 15 Feb 2010 13:02:05 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
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
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel