[Geany-devel] Build config dialog change

[Jiří Techet]

On Mon, Jun 14, 2010 at 03:20, Lex Trotman <elextr at gmail.com> wrote:
>> Of course, I don't have this version in mind when posting my comments.
>> Your current version is alright for 0.19.1.
>>
>
> Ok thanks, as you probably can tell I'd rather move on than try to
> tart up what I consider to be a fundamentally bad UI.
>
>>> 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.
>>
>
> see below for another suggestion.
>
>>>
>>>> 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
>
> I should have pointed out that there is no reason for the combined
> dialog to not be openable from several places, project, prefs, build
> menu.  Personally I like that it can be accessed quickly from the
> build menu, rather than having to dig through the prefs, but as I say
> activating the combined dialog from multiple points is no problem.
>
>>
>> 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"
>> :-)
>
> You should use the proper terminology, you are editing the user's
> configuration files in ~/.config or -c , so they are called "user"
> configuration, they override the "system" configuration files in
> --prefix which would require root to edit and are overwritten when
> Geany is upgraded so there is no dialog to edit them.
>
> No global or ...  super global ?!  :-)
>
>  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?
>
> I'm not sure what we gain by separating the project and user settings.

(using the correct terminology)

>From what I understand how the dialog will look like it will only
display the currently used commands, correct? If so, then I expect it
won't be possible to edit the user commands that have been overridden
by the project commands. This will be a bit unfriendly to the user. If
he decides he wants to edit the user commands, he'll have to close the
project, edit the commands, and reopen the project again (if he wants
to continue in his work on the project). I think the two-mode
operation (no project open, project open) will be a bit confusing - in
one mode you'll edit the user commands only, in the other mode you'll
half edit the user commands and half the project commands, depending
on what has been overridden. And the "mode" depends on something
external from the dialog itself and it won't be apparent to the user,
what it is. The two-tabs dialog would eliminate the confusion.

>  Remember the idea with the new dialog is to have two levels, the
> first level simply shows a table with what the menu *does now*, that
> is for the current file, for each menu item in order of the menu it
> has:
>
> * the label,
> * the command,
> * the working directory,
> * where the command comes from
> * an edit details button which
>
> pops up a subdialog with apply, cancel, ok buttons, and fields for the
> things you can edit (which is where the plugin configurator and the
> built in one differ see below), but only for the one menu item.  This
> makes it easy for inexperienced users to see what will happen, and
> they won't even have to think about filetypes
>
> Your filetype combo box would be on that subdialog and if you change
> the filetype whilst there are changed settings that haven't been
> applied you get a prompt to apply or cancel them.  That way there is
> no confusion, you can always see what you are saving.  If you have
> only one prompt at the end there is no way to see what you are saving.
>
> The list of things that can be edited for each source needs to be
> bigger than it is now so that you can configure things like:
>
> * commands to go to "kill" when a build is running,
> * where the output of the command goes ( to the parser and the
> compiler window, to a terminal, or nowhere),
> * which commands can't be run together and so become insensitive
> * and more.
>
> Thats why there is a complex and simple version of the dialog, if all
> you want to do is add -g to the C compile options you don't need to be
> presented with the full capabilities.
>
> Now before you accuse me of making the build system too complicated,
> let me point out that most of these functions are available now, I'm
> just making them explicitly configurable rather than depending on
> position in the menu or some other hidden criteria that is currently
> adding lots of special case code, limiting what can be configured and
> requiring knowledge of these limitations to configure it.

If there is a code like that, it's definitely a good idea to add the
extra options you propose. I'll wait until I see this modified dialog
before accusing you of making things complicated ;-). I expect a huge
amount of information has been lost during the transformation

image in your head -> words -> image in my head

so I'll wait for the final result.

Cheers,

Jiri