Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
On Jan 7, 2007, at 1:03 PM, Bram Moolenaar wrote: Edward Catmur wrote: This patch improves HIG compliance when compiled with FEAT_GUI_GNOME: * Close confirmation dialogs use Save/Discard/Cancel instead of Yes/No/Cancel * GTK_STOCK_SAVE used for Save * Default button placed at end of message dialog, with order passed in set as alternative button order vim_dialog_yesnocancel() is renamed to vim_dialog_savediscardcancel (), because that's all it's used for. Same for vim_dialog_yesnoallcancel(). I'll look into this later. Perhaps Save/Discard/Cancel is better for all GUIs, since you don't need to read the text to know whether yes means save or discard. But it will break the translations. Just being a lurker here, I would vote for this being in all GUIs (not that we get votes here). Having the actual save/discard vs. yes/ no makes it much simpler to look at a message box and know which button to press (probably why the File Changed dialog in Vim is a bit easier to decide what to do than the Save Changes dialog IMO). FWIW, the OS X guidelines also recommend this as well, (though they seem to prefer Don't Save, Discard is better than No). Breaking translations is unfortunate though, but it is a one-time cost (hopefully)... Vim 7.1-type thing? -- Trenton
Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
On Mon, Jan 08, 2007 at 12:14:05PM +0100, Trenton Schulz wrote: I'll look into this later. Perhaps Save/Discard/Cancel is better for all GUIs, since you don't need to read the text to know whether yes means save or discard. But it will break the translations. Just being a lurker here, I would vote for this being in all GUIs (not that we get votes here). Having the actual save/discard vs. yes/ no makes it much simpler to look at a message box and know which button to press (probably why the File Changed dialog in Vim is a bit easier to decide what to do than the Save Changes dialog IMO). Would you also vote for changing the console style dialogs? I mean, console users are normally used to press y or n, when answering these kind of questions. -- Martin
Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
On Jan 8, 2007, at 12:39 PM, Martin Stubenschrott wrote: On Mon, Jan 08, 2007 at 12:14:05PM +0100, Trenton Schulz wrote: I'll look into this later. Perhaps Save/Discard/Cancel is better for all GUIs, since you don't need to read the text to know whether yes means save or discard. But it will break the translations. Just being a lurker here, I would vote for this being in all GUIs (not that we get votes here). Having the actual save/discard vs. yes/ no makes it much simpler to look at a message box and know which button to press (probably why the File Changed dialog in Vim is a bit easier to decide what to do than the Save Changes dialog IMO). Would you also vote for changing the console style dialogs? I mean, console users are normally used to press y or n, when answering these kind of questions. Well, don't you do that by typing :wq/:wq! or ZZ or whatever? Most of the other dialogs on the console version don't ask yes/no questions as far as I have encountered. I think it is a non-issue for the console version... -- Trenton
Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
On Mon, Jan 08, 2007 at 05:05:31PM +0100, Trenton Schulz wrote: Would you also vote for changing the console style dialogs? I mean, console users are normally used to press y or n, when answering these kind of questions. Well, don't you do that by typing :wq/:wq! or ZZ or whatever? Most of the other dialogs on the console version don't ask yes/no questions as far as I have encountered. I think it is a non-issue for the console version... Well, mostly I use ZZ, but sometimes :q, but have :set confirm on, so when there are unsaved changes, there is no need to press :q!, but just y to save the changes, or n do discard them. -- Martin
Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
On 1/8/07, Trenton Schulz [EMAIL PROTECTED] wrote: On Jan 8, 2007, at 12:39 PM, Martin Stubenschrott wrote: Would you also vote for changing the console style dialogs? I mean, console users are normally used to press y or n, when answering these kind of questions. Well, don't you do that by typing :wq/:wq! or ZZ or whatever? Most of the other dialogs on the console version don't ask yes/no questions as far as I have encountered. I think it is a non-issue for the console version... % vim :set confirm iHello, Vim!Esc :q Save changes to Untitled? [Y]es, (N)o, (C)ancel: Sure, [S]ave, (D)iscard, (C)ancel would work - and is better, as it better describes what would happen - but I'd venture so far as to say that 'Y', 'N' are so deeply engrained in peoples minds by now that it would be very irritating to have to hit 'S' or 'D' instead. I know I would be annoyed. Still, perhaps it makes sense to change these as well. And one could allow the user to type 'Y' or 'N' with the old behavior as well. nikolai
Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
On Sun, 2007-01-07 at 13:03 +0100, Bram Moolenaar wrote: Edward Catmur wrote: * Close confirmation dialogs use Save/Discard/Cancel instead of Yes/No/Cancel I'll look into this later. Perhaps Save/Discard/Cancel is better for all GUIs, since you don't need to read the text to know whether yes means save or discard. But it will break the translations. Thanks. I know some GUIs are replete with message dialogs where you have to read the text to know which button to press, but they stick out like a sore thumb in Gnome. As for the string break: looking at the pofiles, a guessed translation (from the existing Save all, Discard all) looks feasible in almost all cases; would it be acceptable for me to attempt that? Also attached is a patch to disable guioptions=t (tearoff menus) when compiled with FEAT_GUI_GNOME, also for desktop consistency. You mean that the default is not to use tearoff menus, one can still have them when wanted. Yes. Sorry for the confusion. Ed
GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
Hi,
This patch improves HIG compliance when compiled with FEAT_GUI_GNOME:
* Close confirmation dialogs use Save/Discard/Cancel instead of
Yes/No/Cancel
* GTK_STOCK_SAVE used for Save
* Default button placed at end of message dialog, with order passed in
set as alternative button order
vim_dialog_yesnocancel() is renamed to vim_dialog_savediscardcancel(),
because that's all it's used for. Same for vim_dialog_yesnoallcancel().
Also attached is a patch to disable guioptions=t (tearoff menus) when
compiled with FEAT_GUI_GNOME, also for desktop consistency.
Ed
--- vim7/src/ex_cmds2.c 2007/01/06 17:32:00 1.1
+++ vim7/src/ex_cmds2.c 2007/01/06 18:16:08
@@ -1369,9 +1369,9 @@ dialog_changed(buf, checkall)
(buf-b_fname != NULL) ?
buf-b_fname : (char_u *)_(Untitled));
if (checkall)
- ret = vim_dialog_yesnoallcancel(VIM_QUESTION, NULL, buff, 1);
+ ret = vim_dialog_savediscardallcancel(VIM_QUESTION, NULL, buff, 1);
else
- ret = vim_dialog_yesnocancel(VIM_QUESTION, NULL, buff, 1);
+ ret = vim_dialog_savediscardcancel(VIM_QUESTION, NULL, buff, 1);
if (ret == VIM_YES)
{
--- vim7/src/message.c 2007/01/06 17:32:00 1.1
+++ vim7/src/message.c 2007/01/06 19:34:08
@@ -3599,7 +3599,7 @@ vim_dialog_yesno(type, title, message, d
}
int
-vim_dialog_yesnocancel(type, title, message, dflt)
+vim_dialog_savediscardcancel(type, title, message, dflt)
int type;
char_u *title;
char_u *message;
@@ -3608,7 +3608,12 @@ vim_dialog_yesnocancel(type, title, mess
switch (do_dialog(type,
title == NULL ? (char_u *)_(Question) : title,
message,
- (char_u *)_(Yes\nNo\nCancel), dflt, NULL))
+#ifdef FEAT_GUI_GNOME
+ (char_u *)_(Save\nDiscard\nCancel),
+#else
+ (char_u *)_(Yes\nNo\nCancel),
+#endif
+ dflt, NULL))
{
case 1: return VIM_YES;
case 2: return VIM_NO;
@@ -3617,7 +3622,7 @@ vim_dialog_yesnocancel(type, title, mess
}
int
-vim_dialog_yesnoallcancel(type, title, message, dflt)
+vim_dialog_savediscardallcancel(type, title, message, dflt)
int type;
char_u *title;
char_u *message;
@@ -3626,7 +3631,11 @@ vim_dialog_yesnoallcancel(type, title, m
switch (do_dialog(type,
title == NULL ? (char_u *)Question : title,
message,
+#ifdef FEAT_GUI_GNOME
+ (char_u *)_(Save\nDiscard\nSave all\nDiscard all\nCancel),
+#else
(char_u *)_(Yes\nNo\nSave All\nDiscard All\nCancel),
+#endif
dflt, NULL))
{
case 1: return VIM_YES;
--- vim7/src/gui_gtk.c 2007/01/06 17:33:18 1.1
+++ vim7/src/gui_gtk.c 2007/01/06 19:11:31
@@ -2121,13 +2121,17 @@ button_equal(const char *a, const char *
}
static void
-dialog_add_buttons(GtkDialog *dialog, char_u *button_string)
+dialog_add_buttons(GtkDialog *dialog, char_u *button_string, int def_but)
{
char**ok;
char**ync; /* yes no cancel */
+char**save;
char**buttons;
int n_buttons = 0;
int idx;
+#ifdef FEAT_GUI_GNOME
+char*def_label = NULL;
+#endif
button_string = vim_strsave(button_string); /* must be writable */
if (button_string == NULL)
@@ -2153,6 +2157,7 @@ dialog_add_buttons(GtkDialog *dialog, ch
*/
ok = split_button_translation(N_(Ok));
ync = split_button_translation(N_(Yes\nNo\nCancel));
+save= split_button_translation(N_(Save));
buttons = split_button_string(button_string, n_buttons);
/*
@@ -2176,28 +2181,54 @@ dialog_add_buttons(GtkDialog *dialog, ch
* since anyone can create their own dialogs using Vim functions.
* Thus we have to check for those too.
*/
- if (ok != NULL ync != NULL) /* almost impossible to fail */
+ if (ok != NULL ync != NULL save != NULL) /* almost impossible to fail */
{
if (button_equal(label, ok[0]))label = GTK_STOCK_OK;
else if (button_equal(label, ync[0])) label = GTK_STOCK_YES;
else if (button_equal(label, ync[1])) label = GTK_STOCK_NO;
else if (button_equal(label, ync[2])) label = GTK_STOCK_CANCEL;
+ else if (button_equal(label, save[0])) label = GTK_STOCK_SAVE;
else if (button_equal(label, Ok)) label = GTK_STOCK_OK;
else if (button_equal(label, Yes))label = GTK_STOCK_YES;
else if (button_equal(label, No)) label = GTK_STOCK_NO;
else if (button_equal(label, Cancel)) label = GTK_STOCK_CANCEL;
+ else if (button_equal(label, Save)) label = GTK_STOCK_SAVE;
+ }
+#ifdef FEAT_GUI_GNOME
+ if (idx == def_but) {
+ def_label = label;
+ continue;
}
+#endif
label8 = CONVERT_TO_UTF8((char_u *)label);
gtk_dialog_add_button(dialog, (const gchar *)label8, idx);
CONVERT_TO_UTF8_FREE(label8);
}
+#ifdef FEAT_GUI_GNOME
+if (def_label != NULL) {
+ char_u *label8;
+ int *idx_arr;
+
+ label8 = CONVERT_TO_UTF8((char_u *)def_label);
+ gtk_dialog_add_button(dialog, (const gchar *)label8, def_but);
+ CONVERT_TO_UTF8_FREE(label8);
+ idx_arr = (int *) alloc((sizeof (int)) * n_buttons);
+ for (idx = 1; idx = n_buttons; ++idx)
+ idx_arr[idx-1] = idx;
Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
On 1/7/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Also attached is a patch to disable guioptions=t (tearoff menus) when compiled with FEAT_GUI_GNOME, also for desktop consistency. Hey, wait! Even gvim for Windows has tearoff menus, which is a great feature, available in no other Windows programs AFAIK. Why disable it in Gnome versions on the pretext that other Gnome programs don't have it? If you don't like the availability of tearoff menus, include :set guioptions-=t in your vimrc, but don't deprive me of this feature. And don't tell me that I can just compile with GTK but without Gnome: I want a Gnome gvim for other reasons, such as the ability to save its session when the KDE window manager closes. Eh, you who want tearoff menus (perhaps the most stupid GUI design choice ever) can include :set guioptions+=t in your vimrc. Not that I'd include 'm' in my guioptions either. Not that I'd run the gui for that matter. This sounds to me like I don't want it, therefore you cannot have it, a form of totalitarianism completely out of place in Vim. Last time I checked, we had a benevolent dictator for a ruler that has ruled to that effect, many times in the past. nikolai
Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
Nikolai Weibull wrote: On 1/7/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Also attached is a patch to disable guioptions=t (tearoff menus) when compiled with FEAT_GUI_GNOME, also for desktop consistency. Hey, wait! Even gvim for Windows has tearoff menus, which is a great feature, available in no other Windows programs AFAIK. Why disable it in Gnome versions on the pretext that other Gnome programs don't have it? If you don't like the availability of tearoff menus, include :set guioptions-=t in your vimrc, but don't deprive me of this feature. And don't tell me that I can just compile with GTK but without Gnome: I want a Gnome gvim for other reasons, such as the ability to save its session when the KDE window manager closes. Eh, you who want tearoff menus (perhaps the most stupid GUI design choice ever) can include :set guioptions+=t in your vimrc. Not that I'd include 'm' in my guioptions either. Not that I'd run the gui for that matter. At the moment I can. If the OP's patch makes it to the official distributions (Bram forbid!) it won't work anymore This sounds to me like I don't want it, therefore you cannot have it, a form of totalitarianism completely out of place in Vim. Last time I checked, we had a benevolent dictator for a ruler that has ruled to that effect, many times in the past. nikolai Benevolent dictator is a contradiction in terms. There used to be enlightened despots, but even with that I have a problem: there are no safeguards to prevent an enlightened despot from becoming a despot plain and simple. Removing features sounds extremely un-Vim-like to me. Best regards, Tony.
