On Mon, Jun 14, 2010 at 03:20, Lex Trotman elextr@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.
- 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