On Fri, 12 Feb 2010 22:59:59 +1100 Lex Trotman elextr@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