On 12 February 2010 05:32, Nick Treleaven <nick.treleaven@btinternet.com> wrote:
> On Thu, 11 Feb 2010 09:04:07 +1100
> Lex Trotman <elextr@gmail.com> wrote:
>
>> On 11 February 2010 00:01, Nick Treleaven <nick.treleaven@btinternet.com> wrote:
>> > I think making all functionality available is overkill. We've got to
>> > come up with a design that makes sense for each set of commands.
>>
>> Yes, but hard coding such restrictions increases the complications of
>> the code (those special cases) and then forces users who need
>> something else to change code not just configure.  Including having to
>> change existing special cases (or to ask you to change it).  There
>> should be much less work to create and maintain a good general
>> solution.
>
> The goal is to provide understandable options, not to simplify
> implementation. I doubt that the implementation is/will be too complex
> though.
>
> The problem with mass configurability is that it can still harm the
> casual user when they accidentally change something then have to go and
> study the manual.
>
> I'm actually arguing for limiting complexity, options should be
> specific (see below).

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?


>
>> > For example, you can only have one build command stopable, unless you
>> > make new build tabs in the message window. I think this is too complex.
>>
>> Agree that there should be only one output to the message window, and
>> I have already written that in the spec. (I like the tabbed idea,
>> maybe Geany version 3.0 :-)  But the dialog wouldn't show that, its a
>> function of the menu operation.  When a parsed command is run, all the
>> other parsed menu items become insensitive.
>>
>> For stopability, (if thats a word) the decision which command is
>> stopable has to be made at the time a menu item is selected, the one
>> thats selected becomes stopable, the other parsed menu items become
>> insensitive.
>>
>> But there are some build commands that should NOT be stopable, ever,
>> because of the risk of corruption ( see past discussions with Thomas
>> and Enrico), so stopability needs to be able to be turned off for
>> them, and since in general we don't know what commands are running, it
>> has to be off by default.
>
> 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.

> 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.

>
>> > 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.
>>
>> Yes thats a reasonable way to do it, but what are the groups and what
>> are their characteristics.  I couldn't come up with a sensible set of
>> fixed groupings that don't unreasonably limit the behaviour.
>>
>> 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?

>
>> So I gave up and made everything settable :-) no special cases or
>> inconsistent operation :-)  but as you and Enrico say, making the
>> configuration GUI approachable is a problem :-(
>>
>> It would be possible to have a separate dialog to define new groups
>> and their characteristics so all that needs to be set in the main
>> configuration dialog is the group name from a combo box.
>>
>> The advanced dialog would only have 6 characteristics to set, or
>> actually only 4 when you consider some are just an enable for the
>> following value.
>>
>> Default groups and their characteristics:
>>
>> - Internal - internal and which internal item
>> - Parsed - parsed, not stopable, regex
>> - Execute - to terminal, stopable, stop label "Stop"
>> - Execute no terminal - no terminal, stopable, stop label "Stop"
>>
>>  Lets see what that can do for us.
>
> 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.

Cheers
Lex

> This is perhaps a bit vague but I'm trying to say the extra
> configurability should be linked to what it's needed for, not an
> option for every single command.
>
> Regards,
> Nick
> _______________________________________________
> Geany-devel mailing list
> Geany-devel@uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>