[Feat] wxGUI: consistent dialog button layout and labelling

nilason commented 3 years ago

Introduction

This is a proposal for a more consistent and intuitive implementation of dialog button layout and labelling. This issue did surface working on issue #743 and was touch upon again with the PR #818. Any suggestions, opinions on this issue and its implementation is highly welcome.

The dialogs in current GUI display a very disparate layout of buttons, almost with one button layout style per dialog. Often all buttons are grouped together, with various order; and buttons labeled Close and Cancel are used semingly interchangeable.

I'm proposing changes to address this present state, based on a survey of common practices for different platforms (see references below) with following main points:

Split buttons into a "main group" and an "alternative/optional group"
The main buttons consists typically of a main action button (eg. OK) and it's negating button (e.g. Cancel). This group is aligned to the right of the dialog window.
The optional button group consists of other buttons not directly used for the intentional use of the dialog (e.g. Help, Copy Command etc.) or alternatives to the main action. This group is aligned to the dialog window's left side.
The optional button group may in turn be split in two in some rare cases (e.g. mapcalculator), resulting in an additional centered group.

Labelling of Buttons

The main action button should, if possible, be labelled with an imperative verb, e.g. Import, Reproject (not OK).

Cancel vs. Close

I've previously made the argument https://github.com/OSGeo/grass/pull/818#discussion_r504713766 in favour for using Cancel over Close. I reiterate that position here, but only in those cases where operation is aborted and any/all changes are rewound. For dialogs with e.g. Apply or the generated module dialogs (which stays open after being run and the result will not be undone upon closing the dialog), I'd prefer labelling the button Done (not Close).

Order of Buttons

Ideally, support for Right-to-left languages might be considered, but this is perhaps better left for future enhancement.

References (Human Interface Guidelines)

Windows Mac GNOME

Example of Proposed Changes

generated module dialogs (gui_core/forms.py) :

# current
|                      [Close]    [Run]    [Copy]    [?]                      |

# new
|    [?]    [Copy]                                         [Done]    [Run]    |

r.import / v.import :

# current
|                                                      [Close]    [Import]    |

# new
|                                                     [Cancel]    [Import]    |

d.vect / d.rast :

# current
|                 [Close]    [Apply]    [Ok]    [Copy]    [?]                 |

# new
|    [?]    [Copy]                               [Done]    [Apply]    [OK]    |

mapcalculator :

# current
|                [Load]    [Save]    [Copy]        [?]    [Run]    [Close]    |

# new
|    [?]    [Copy]             [Load]    [Save]               [Done]  [Run]   |

vector attribute manager (dbmgr/manager.py) :

# current
|                                          [Clear]    [Refresh]    [Close]    |

# new
|    [Clear]                                           [Done]    [Refresh]    |

sql builder (dbmgr/sqlbuilder.py) :

# current
|                                [Clear]    [Verify]    [Apply]    [Close]    |

# new
|    [Clear]    [Verify]                                 [Done]    [Apply]    |

gui settings :

# current
|                       [Cancel]    [Save for this session only]    [Save]    |

# new
|    [Save for this session only]                       [Cancel]    [Save]    |

create new location :

# current
|    [?]                                      [Back]    [Next]    [Cancel]    |
|    [?]                                    [Back]    [Finish]    [Cancel]    |

# new
|    [?]                                      [Cancel]    [Back]    [Next]    |
|    [?]                                    [Cancel]    [Back]    [Finish]    |

create new mapset :

# current
|                                                         [Cancel]    [OK]    |

# new
|                                                     [Cancel]    [Create]    |

reprojection (Data tab) :

# current
|                                                  [Cancel]    [Reproject]    |

# new (same)
|                                                  [Cancel]    [Reproject]    |

Map Swipe / Select raster maps :

# current
|                                              [Cancel]    [Apply]    [OK]    |

# new (same)
|                                              [Cancel]    [Apply]    [OK]    |

Fetch & install extension :

# current
|    [?]                                              [Close]    [Install]    |

# new
|    [?]                                               [Done]    [Install]    |

Georectify :

# current
|                                             [Back]    [Next]    [Cancel]    |

# new
|                                             [Cancel]    [Back]    [Next]    |

Vector Network Analysis Tool / Settings :

# current
|    [Apply]    [Save]    [Close]                                             |

# new
|                                            [Cancel]    [Apply]    [Save]    |

marisn commented 3 years ago

Do not miss out HIG for KDE too. GNU/Linux is not only Gnome! https://hig.kde.org/index.html

"OK | Cancel" consistency should be provided by the toolkit thus allowing automatic reorganisation based on user preferences. Here is an example how "good job" (default config without tweaks) is done by current toolkits on my system (KDE file open dialog on the left, GTK – on right; "Atvērt" = "Open", "Atcelt" = "Cancel"): attels

Overall for your proposal: :+1: for greater consistency.

I leave you here meditating on how many times I close some dialog by pressing wrong button just because I just switched to a different window (and thus different HIG).

nilason commented 3 years ago

@marisn Thanks for the input, greatly appreciated.

"OK | Cancel" consistency should be provided by the toolkit thus allowing automatic reorganisation based on user preferences.

This will not be trivial as there is no built-in way for detection of user prefs on platform level in wxPython (at least that I'm aware of after brief survey).

Detecting GUI flavour under Linux may need quite complicated code (but correct me if I'm wrong on this). One way to implement this is with platform detection, with "Cancel | OK" order as default, and "OK | Cancel" order for Windows – and the possibility to set (reverse) the order in GUI Settings. In this case, this has to be set for KDE to achieve the Window's style.

petrasovaa commented 3 years ago

The easiest is to use https://wxpython.org/Phoenix/docs/html/wx.StdDialogButtonSizer.html, which we already do in some places.

marisn commented 3 years ago

This will not be trivial as there is no built-in way for detection of user prefs on platform level in wxPython (at least that I'm aware of after brief survey).

wx.StdDialogButtonSizer? Damn'! Race condition :D

nilason commented 3 years ago

wx.StdDialogButtonSizer

I did look at that, figured it might be difficult with the cases with more than two buttons: e.g. [Cancel] [Back] [Next] or [Done] [Apply] [OK], but it may perhaps work...

cmbarton commented 3 years ago

I know I'm late to the show, but I think that this is a great idea and worth working out how to implement it. Such consistency with widespread standards is really valuable

petrasovaa commented 3 years ago

Looking into this, I would perhaps keep Close/Done for r.import rather than change it to Cancel. In terms of behavior, it's similar to module dialogs.

I am not sure Done is better than Close, I would personally prefer Close as more explicit. I didn't look at the linked HIG, but e.g. QGIS uses Close (Open Data Source Manager).

OSGeo / grass