On Fri, 12 Feb 2010 22:59:59 +1100 Lex Trotman <ele...@gmail.com> wrote:
> What I'm arguing is that it isn't possible to sensibly decide what > limitations to apply without sounding like a dictator, "do it my way or not > at all". Let me try to ask some leading questions referring to various > restrictions in the current system. > > Why do all non-filetype dependent commands have to have their output parsed? > and so block all other commands? So now I can't use a pair of tools > > together. What about tools that display output in a GUI, eg viewers, I have > to close them and lose the output to be able to run another command. > > Same argument for filetype dependent commands of course, but compounded by > having different tools for different languages, but still if one is running > no others can. Even if their is no parsed output to be confused. > > 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? IMO the solution to all of this is to use Execute commands, not build commands. Build commands are things that you want geany to monitor during a build. > > I think the 'make everything as configurable as possible' idea is one > > that leads to very complex dialogs, and also IMO is against the design > > of Geany. There may be other ways. > > Well, I think that making everything configurable stops you having to wire > logic in the code making it simpler. > > > > > We could solve the stop issue by having 2 stop commands, one for any > > build command and one for the execute command (as current). > > > > Another band-aid (R J&J :-) solution adding more special cases. No, you're saying add a setting for every possible command, I'm saying, just add a dialog. You're suggesting more work ;-) > > Each stop command would prompt 'Killing the process may be unsafe. Are > > you sure?'. > > Thats a good idea, but better to configure it off so only a user that at > least understands the question will enable it, rather than asking a question > of a user who has no idea of the answer. If the user doesn't understand it, they shouldn't be killing things ;-) But my point was really that having lots of settings for each command is one approach to doing this, one I (and I think Enrico) don't like. There are other ways to add configurability/flexibility which can be simpler to understand. > >> > 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. ... > >> 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. > > > > Maybe add an execute option for this, I don't think any build commands > > should need this. > > Why not? See comments above, you are still thinking in terms of a "make" > type builder whereas it could be anything. Since the "make" commands can be > programmed from a project file it makes perfect sense that it may be a web > CMS or anything else associated with the project. > > > > > I think it's good to keep build and execute commands separate. They are > > intended for different things. > > They are only different in the C/C++ workflow, in interpreted languages > build=execute, in web languages view=execute, if either can execute any > command how can you separate them? If you don't want parsing, use execute commands. This can make understanding the build system easier for the user. > > This isn't what I meant, though I wasn't clear. I think we should have > > simple filetype build commands, 'make' commands, execute command(s), and > > then [a bit] more configurable options for project commands. > > > > As I said above, this is one particular workflow, no problem if the default > configuration follows that, but I don't see its good to LIMIT it to that. I might have forgotten to say: I don't think we should deny users any features, just that the more advanced things can be done in a way that doesn't complicate everything else. Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel