Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • 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 *
    Message 1 of 12 , Jan 6, 2007
    • 0 Attachment
      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
      ... At the moment I can. If the OP s patch makes it to the official distributions (Bram forbid!) it won t work anymore ... Benevolent dictator is a
      Message 2 of 12 , Jan 6, 2007
      • 0 Attachment
        Nikolai Weibull wrote:
        > On 1/7/07, A.J.Mechelynck <antoine.mechelynck@...> 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.
      • Nikolai Weibull
        ... (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
        Message 3 of 12 , Jan 6, 2007
        • 0 Attachment
          On 1/7/07, A.J.Mechelynck <antoine.mechelynck@...> wrote:

          > Nikolai Weibull wrote:

          > > On 1/7/07, A.J.Mechelynck <antoine.mechelynck@...> 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

          (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.

          > > > 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.)

          > 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
          ... 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
          Message 4 of 12 , Jan 7, 2007
          • 0 Attachment
            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.

            > 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.

            --
            Managers are like cats in a litter box. They instinctively shuffle things
            around to conceal what they've done.
            (Scott Adams - The Dilbert principle)

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ download, build and distribute -- http://www.A-A-P.org ///
            \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
          • Edward Catmur
            ... 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
            Message 5 of 12 , Jan 7, 2007
            • 0 Attachment
              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
            • Trenton Schulz
              ... 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
              Message 6 of 12 , Jan 8, 2007
              • 0 Attachment
                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
              • 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
                Message 7 of 12 , Jan 8, 2007
                • 0 Attachment
                  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
                • Trenton Schulz
                  ... 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
                  Message 8 of 12 , Jan 8, 2007
                  • 0 Attachment
                    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
                  • Martin Stubenschrott
                    ... 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
                    Message 9 of 12 , Jan 8, 2007
                    • 0 Attachment
                      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
                    • Nikolai Weibull
                      ... % vim ... iHello, Vim! ... Save changes to Untitled ? [Y]es, (N)o, (C)ancel: Sure, [S]ave, (D)iscard, (C)ancel would work - and is better, as it
                      Message 10 of 12 , Jan 8, 2007
                      • 0 Attachment
                        On 1/8/07, Trenton Schulz <twschulz@...> 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
                      Your message has been successfully submitted and would be delivered to recipients shortly.