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) 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.
Also I had a "doh" moment about the manual, you don't have to look in the doc directory, its in the help menu :-S
@Nick, A second problem I have discovered along the way seems to have been introduced by one of the changes to the translation handling that were made recently. Since I don't understand quite why the changes were made I am not sure what to do and why it didn't appear previously.
To demonstrate the problem make yourself a new garbage project so as to not change anything important, then using one of the blank menu items, set a command but not a label, click ok. See the "interesting" menu item that results. AFAIK this did not happen before.
Setting a command without a label is silly, but someone is bound to do it :-) and the result is sorta startling, though not harmful.
Cheers lex
On Sat, 12 Jun 2010 15:44:06 +1000, Lex 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:
- settings being overridden from another source are insensitive
(current behaviour) 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.
Sorry, no. I don't have time to check it carefully and release is going to happen today.
Regards, Enrico
2010/6/12 Enrico Tröger enrico.troeger@uvena.de:
On Sat, 12 Jun 2010 15:44:06 +1000, Lex 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:
- settings being overridden from another source are insensitive
(current behaviour) 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.
Sorry, no. I don't have time to check it carefully and release is going to happen today.
Regards, Enrico
Ok, thats why I put it in unstable.
Cheers Lex
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, Jun 12, 2010 at 07:44, Lex Trotman elextr@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:
- 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?
- 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. If only I could erase my memory from the last few days :-) But I like it.
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) 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)
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.
Cheers,
Jiri
On 13 June 2010 07:46, Jiří Techet techet@gmail.com wrote:
On Sat, Jun 12, 2010 at 07:44, Lex Trotman elextr@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:
- 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.
- 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:
- 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.
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. 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.
- 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.
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
Cheers Lex
Cheers,
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sun, Jun 13, 2010 at 00:25, Lex Trotman elextr@gmail.com wrote:
On 13 June 2010 07:46, Jiří Techet techet@gmail.com wrote:
On Sat, Jun 12, 2010 at 07:44, Lex Trotman elextr@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:
- 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.
- 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:
- 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.
- 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
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. 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.
Cheers Lex
Cheers,
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
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
(using the correct terminology)
Thanks :-)
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.
It will be possible.
Because the subdialog shows only one menu item's settings, there is plenty of space to show all the sources which you can edit at once, so you can see what overrides what. Of course the project settings will be insensitive if no project is open.
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.
This sort of thing is what I'm trying to avoid.
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
Yeah, GUIs are hard to describe and even harder to read in words :-)
So thanks for trying, it helps to get my thoughts clear if I've got to describe it.
Cheers Lex
so I'll wait for the final result.
Cheers,
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel