<br><br><div class="gmail_quote">On 16 February 2010 03:09, Nick Treleaven <span dir="ltr"><<a href="mailto:nick.treleaven@btinternet.com">nick.treleaven@btinternet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mon, 15 Feb 2010 13:02:05 +0000<br>
<div class="im">Nick Treleaven <<a href="mailto:nick.treleaven@btinternet.com">nick.treleaven@btinternet.com</a>> wrote:<br>
<br>
</div><div class="im">> > Since any command can be run by the build menu, it can be a long-running<br>
> > command, so why not allow a competent user to decide that it is safe to stop<br>
> > it if its going wrong?<br>
<br>
</div>Sorry, my comment about execute commands was not in reply to the<br>
above, only about commands that you don't want to be parsed in the<br>
Compiler tab.<br></blockquote><div><br>Understand.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
For the stop issue, I don't think a dialog is that bad. How often do<br>
you need to stop things? </blockquote><div><br>Usually not for weeks then several times in a row ;-)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
You could still have a pref, on by default,<br>
for whether to ask/warn the user first or not.<br></blockquote><div><br>What ANOTHER setting? :-D HeHe, sorry I couldn't resist....<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
I would prefer for each new 'feature' like stopability or concurrent<br>
commands or whatever to be discussed separately, otherwise it's<br>
difficult to find the best solution. You're saying look at all these<br>
things people might want from the build system, hence a big and<br>
complicated configuration dialog is necessary. I'd prefer to look at it<br>
from where we are, what is needed incrementally.<br></blockquote><div><br>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.<br>
<br>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.<br>
<br>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... ;-)<br><br>And the complex full configuration dialog could be a plugin.<br>
<br>Cheers<br>Lex<br><br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5"><br>
Regards,<br>
Nick<br>
_______________________________________________<br>
Geany-devel mailing list<br>
<a href="mailto:Geany-devel@uvena.de">Geany-devel@uvena.de</a><br>
<a href="http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel" target="_blank">http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel</a><br>
</div></div></blockquote></div><br>