This report was created based on a proposal from the following link:

https://bugzilla.gnome.org/show_bug.cgi?id=691681#c41

To quote the proposal:

> With my proposal for buttons the right most button is always the do
> nothing, close the dialog button, but just changes it label between
> [Cancel] and [Close] depending whether there are any pending changes
> or not.  The [Apply] button only becomes active when there are pending
> changes in the dialog to apply.
>
> If we don't like the labels changing we should stick with [Cancel] as
> the right most, close the dialog and do nothing button.

Responding to this proposal proved to be more difficult that I
initially thought and required some further investigation.

While investigating I discovered problems with the placement of
buttons, and the naming of buttons within GParted.  Following are a
list of issues, and a response to the "right most button" proposal.


LIST OF BUTTON NAME AND PLACEMENT ISSUES
========================================


I1)  CONTROL OF BUTTON PLACEMENT (NOT OURS?)

On the issue of button placement, I have discovered that we do not
appear to have complete control over the location of the buttons.

When labelling a partition, the displayed button order is as follows:

In *K*ubuntu 12.04:              [  OK  ]   [Cancel]

In    Ubuntu 12.04:              [Cancel]   [  OK  ]

Hence there appears to be something behind the scenes that can impact
button placement.  I suspect that some underlying software is trying
to enforce button order placement based on the button name.


I2)  GPARTED "ABUSE" OF THE [APPLY] BUTTON

I think we might be abusing the GNOME definition for the [Apply].
Often in GParted we use [Apply] to mean [Queue Operation].  The GNOME
HIG states:

  Apply
     Applies all the settings in the window, but does not close the
     window in case the user wishes to change their mind.

  Cancel
     Resets all settings in the window to those that were in force
     when the window was opened. Note: this must undo the effects of
     all applications of the Apply since the window was opened, not
     just the most recent one.

  OK
     Applies all settings in the window, and closes the window.

See,
https://developer.gnome.org/hig-book/3.0/windows-utility.html.en#windows-explicit-apply

In GParted when we use the [Apply] button we are not using "Explicit
apply windows", but so far I have not found any other guideline that
governs the use of the [Apply] button.


I3)  THE [CANCEL] BUTTON ALMOST NEVER APPEARS ON THE RIGHT

From the GNOME HIG I have looked up the following on button placements:

<1>  EXPLICIT APPLY WINDOW BUTTONS
     [ Help ]               [Apply ]   [Cancel]   [  OK  ]

<2>  ALERT BUTTONS
     [ Help ]            [Alternate]   [Cancel]   [Affirmative]

<3>  MODAL DIALOG BUTTONS
                                       [Cancel]   [  OK  ]

<4>  COPYING FILES
                                                  [Cancel]

The only time I have seen the [Cancel] button on the right is when it
is the only button in the dialog.  From these examples it appears that
the button that "performs an action" is always to the right of the
[Cancel] button.

An exception to this occurs when there is more than one "performs an
action" button.  In this case the additional buttons are placed to the
left of the [Cancel] button.

References:
<1>
https://developer.gnome.org/hig-book/3.2/windows-utility.html.en#windows-explicit-apply
<2>
https://developer.gnome.org/hig-book/3.2/windows-alert.html.en#alert-button-order
<3>
https://developer.gnome.org/hig-book/3.2/controls-buttons.html.en
<4>
https://developer.gnome.org/hig-book/3.2/windows-progress.html.en



RESPONSE TO RIGHT MOST BUTTON PROPOSAL
======================================

Based on the above reasons, I do not think we should place the
[Cancel] button on the right.  The only exception is if [Cancel] is
the only button.


NEW BUTTON NAME PROPOSAL
========================

Since GParted seems to abuse the [Apply] button, I propose that we
avoid the use of [Apply] and place the "perform an action" button on
the right.  Further to improve the clarity of the button name I
suggest we prefix "Queue" in front of the name for actions which are
queued.

For example, the buttons for the Label operation would be:

                     [Cancel]   [Queue Label]


Comments and suggestions are welcome.