[Geany-devel] Build config dialog change

[Jiří Techet]

On Sun, Jun 13, 2010 at 00:25, Lex Trotman <elextr at gmail.com> wrote:
> On 13 June 2010 07:46, Jiří Techet <techet at gmail.com> wrote:
>> On Sat, Jun 12, 2010 at 07:44, Lex Trotman <elextr at gmail.com> wrote:
>>> Hi Nick, Enrico, Jiri,
>>>
>>> I have made a version of build such that In the build config dialogs,
>>> that is both "set build commands" dialog and project properties tab:
>>>
>>> 1. settings being overridden from another source are insensitive
>>> (current behaviour)
>>
>> Why can't one change the global commands when they are overridden by
>> the project ones?
>
> Because of the potential confusion if you change it and nothing
> happens because its overridden it was decided to make it insensitive.

This could be editable in the "one more brainstorming idea" of mine below.

>
>>
>>> 2. fields where the setting is set from another source but the source
>>> edited by this dialog can override that setting is shown in grey (the
>>> colour change is new)
>>> 3. when you enter a field (or click on the label button) the text
>>> changes to normal colour to indicate that this source is now
>>> controlling the setting (the colour change is new)
>>> 4. When a row is cleared the text returns to grey as the original
>>> source is no longer being overridden (the colour change is new)
>>>
>>> This changed the way the conditions to save the setting were calculated.
>>>
>>> Because this is more than a trivial change I have committed it to the
>>> unstable branch (and a second one to remove a debug printf oops) so
>>> Nick/Enrico can check it to see if they are happy for it to go into
>>> 0.19 to help reduce the confusion.
>>>
>>> @Jiri I hope this makes things clearer.
>>
>> This is MUCH better than before. The only problem might be that the
>> user might not know what the change of the color means. (The problem
>> with me now is that I understand completely what geany does so I can't
>> look at it independently enough to see what a user with no knowledge
>> about it will think
>
> That of course is very much my problem as well. :-)
>
> . If only I could erase my memory from the last few
>> days :-) But I like it.
>>
>
> Yes, it took a long time to disentangle the misunderstanding from
> issues around the plugin, hopefully just a user's confusion would be
> more obvious.
>
>> So just to summarize what I see as the remaining problems and what's missing:
>> 1. Clearer indication that filetype commands change for different
>> languages (I'd also like to see the language selectable in the dialog)
>
> The heading of the filetype commands states the language.

Not for the execute commands.

>
>  This is made up of the language name and the word "commands".  That
> combination still makes sense when translated into most languages, the
> more complex we make the heading the less likely that is.
>
> Making it selectable will be considered for build system 2.0 but its
> too much for this version.

Of course, I don't have this version in mind when posting my comments.
Your current version is alright for 0.19.1.

> And as I explained I'm don't like UIs that
> save hidden changes, as will happen if you make changes to several
> filetypes, and having a reminder dialog all the time is annoying.

Well, having the reminder is less annoying than having to close the
dialog, find the file with the extension whose commands you want to
edit and open the dialog again. It means no extra annoyance if you use
it the same way you do now.

>
>> 2. Grouping execute and build commands together so it's clear that
>> they are per-filetype (now I have an idea for name substitution for
>> "non-filetype" - maybe "filetype-independent" could be clearer)
>>
>
> Not changing for 0.19, string freeze was weeks ago.

Of course, I don't expect this for 0.19.

>
>> And I have one more idea - wouldn't it be better to put the contents
>> of the "set build commands" dialog as a new tab in the "preferences"
>> dialog? This would mean that there are only two settings dialogs - the
>> preferences dialog for global options and "project properties" for the
>> project ones.
>>
>
> This won't change for 0.19 and as I keep saying the intention for the
> next version is to have a combined dialog

OK, here comes the idea how to make the combined dialog in a slightly
different way - I find the way you propose it a bit too complicated.
The key idea is that the dialog will consist of 2 tabs - one for
global commands (I call the ones you call "global" as "superglobal"
:-) and one for project commands. If no project is open, only the
global tab appears (or no tab is displayed at all) - the contents of
the tab will be the same as the current "set build commands" dialog.
If a project is open, then there will be both tabs. In addition, after
the opening the active tab will be the tab with project build commands
(including the graying out for global commands). So when the user
opens the dialog, he will always see the commands that are currently
used. I think that in this case the overridden global commands don't
have to be disabled - the user will have to click the "global
commands" tab before so he'll know what he is editing.

What do you think about this option?

Cheers,

Jiri