GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)

[Edward Catmur]

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

[A.J.Mechelynck]

Post by Edward Catmur
Hi,
* 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().

Yes/No seems more intuitive to me. And what about consistency with other
flavours of Vim?

Post by Edward Catmur
Also attached is a patch to disable guioptions="t" (tearoff menus) when
compiled with FEAT_GUI_GNOME, also for desktop consistency.
Ed

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.

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.


Best regards,
Tony.

[Nikolai Weibull]

Post by A.J.Mechelynck

Post by Edward Catmur
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.

Post by A.J.Mechelynck
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

[A.J.Mechelynck]

Post by Nikolai Weibull

Post by A.J.Mechelynck

Post by Edward Catmur
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

Post by Nikolai Weibull

Post by A.J.Mechelynck
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.

[Nikolai Weibull]

Post by A.J.Mechelynck

Post by Nikolai Weibull

Post by A.J.Mechelynck

Post by Edward Catmur
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

(Seriously, does it really make sense to write "OP", which I assume
means "Original Poster", instead of "Ed"? We're not in the
military...we don't need acronyms and abbreviations for everything.
It's not cool and it's not helpful. It just makes reading what you've
written more difficult. I'm not trying to police this mailing list,
but come on, what's the point? And if I ever see something like YMMV,
IANAL (hey, if you're not a lawyer, then why are you giving legal
advice in the first place?), or IAHFRTOUAAATEM (I Am , However, A
Fucking Retard That Only Uses Acronyms And Abbreviations To Express
Myself) on this list, I'll seriously consider unsubscribing.)

All his patch does is remove 't' from the default value of
'guioptions' for UNIX GUI builds that aren't Mac OS builds that have
GNOME support enabled. It's quite clear if you look at the diff.

Post by A.J.Mechelynck

Post by Nikolai Weibull

Post by A.J.Mechelynck
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.

"Benevolent dictator" is a contradiction in terms.

And that's the joke. (And if Bram ever goes off the deep end, we'll
always have the source - although I don't see who'd pick it up.)

Post by A.J.Mechelynck
Removing features sounds extremely un-Vim-like to me.

Again, nothing is being removed.

(Coincidentally, I consider not adding features extremely Vim-like.)

nikolai

[Bram Moolenaar]

Post by Edward Catmur
* 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.

Post by Edward Catmur
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.

[Edward Catmur]

Post by Bram Moolenaar

Post by Edward Catmur
* 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?

Post by Bram Moolenaar

Post by Edward Catmur
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

[Trenton Schulz]

Post by Bram Moolenaar

Post by Edward Catmur
* 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

[Martin Stubenschrott]

Post by Trenton Schulz

Post by Bram Moolenaar
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

[Trenton Schulz]

Post by Martin Stubenschrott

Post by Trenton Schulz

Post by Bram Moolenaar
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

[Martin Stubenschrott]

Post by Trenton Schulz

Post by Martin Stubenschrott
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

[Nikolai Weibull]

Post by Trenton Schulz

Post by Martin Stubenschrott
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