New gedit 3 design - TODO

before for 3.12

• revisit all css alignment details (e.g. file browser toolbar and tabs, bottom of filebrowser and statusbar)
• the close confirmation dialog was ported to the new "style" but the theme part is still missing and it looks bad... if it does not happen in time we need to revert
• translation issues with the items in the appmenu

Nice to have for 3.12 (if someone makes patches)

• support for alternative menus / no CSD: it would be nice to detect different environment and adapt, this was discussed with desrt etc and should be fairly easy (and also important for OSX). This is not a blocker but patches from the interested parties would be very welcome. Done for OSX

• port third party plugins (well, we cannot really do all the work, but listing it here if someone wants to help)
• more work on CSD dialogs: most important ones have been ported, but there are more in plugins etc

Future stuff

• popover for the gear menu -> the problem is that is big and popovers do not exit the window, would also be nice to rework using some buttons in the popover as seen in the mockups

• rethink new /new tab: maybe a popover that also includes quickopen? But it's buggy.

• encoding dialog / selection: there is a patch that just ports it to CSD, but a better idea would be to just change this UI completely

• rethink the statusbar: use an overlay at the bottom right with just the ln/col that expands? use a revealer?
• Write a better documentation to port plugins…

Usability regressions

• If only one document is shown, the tabs are not shown in the notebook, so there is no tooltip to know the encoding and the mime type. It's a bit ugly to create a new tab just to be able to see the tooltip of the other tab.

  • I wouldn't expect the tooltip to have more information that the full tab title (when it is ellipised). I'd consider the statusbar and/or the properties dialog to provide that information instead. ~~ AntónioFernandes

• In the main menu (the hamburger button), there are no tooltips for the three buttons at the top (it's hard to know that the first is the revert/reload action). It's normally fixable, for example Nautilus 3.24 has tooltips for the buttons in its menu.
• The UI is less self-discoverable:
  • For example the tabs group feature is available when doing a right click on a tab. One has to know that there are some actions there too… With a traditional menubar, all the possible actions in the application were discoverable by browsing the menu.
  • Also, with a traditional design, it's convenient to have the keyboard shortcuts documented at the same place as where the feature is available in the menu, it's more logical. When a user repeatedly goes to the traditional menu to activate a certain action, if that action has a keyboard shortcut, at some point the user might read the keyboard shortcut and try it; on the other hand, with the new design, the keyboard shortcuts are documented at a completely different place, so it can be hard to know if a certain action in the menu has a corresponding keyboard shortcut.
  • The app menu is hard to discover, and some actions are only available there, for example to access the preferences dialog (but it's a general problem in GNOME 3).
  • Some features are available only through keyboard shortcuts (!), like Ctrl+Shift+T to reopen the most recently closed tab.
  • With the traditional menubar in gedit, when hovering a menu item there was a longer description in the statusbar. With the longer description it was possible to better understand the action, without the need to read the user manual (I think that most users never open the user manual anyway).

• Some actions are now convenient to use only through keyboard shortcuts, like the undo/redo (before those actions were present in the toolbar). To do several undo's with the mouse, we now have to right click -> undo -> right click -> undo -> etc, so it is clearly not convenient. With the traditional toolbar it required just one click. Not all users use keyboard shortcuts, keyboard shortcuts are more for "power users", so it's important that the GUI is convenient to use with the mouse too (I think that most gedit users use it just to write some quick notes). Also the redo action doesn't have a consistent keyboard shortcut across applications, for example in gedit it is Ctrl+Shift+Z but in GIMP it is Ctrl+Y, so for users who often use those two applications, using the keyboard shorcuts for the undo/redo is not convenient.

  • I think optimizing for [un/re]doing using keyboard shortcuts is ok here, as Ctrl+Z is rather well known, and gedit is no good for unexperienced users anyway. If Ctrl+Y is unused in gedit, supporting both shortcuts may be an option. If gedit expects to be productively used on touch screens-only use, perhaps Undo/Redo should be in the header menu instead of the context menu. ~~ AntónioFernandes

• A less important regression: for some actions it now takes more clicks, for example to activate the spell-checking and changing the language, before it was Tools -> menu item, now it is Hamburger menu -> Tools -> menu item (one more click).