Single Window

The page about the graphical layout of the single window user interface.

Previous suggestions

Previously, ideas for this topic were collected at the ​WxPython-based GUI for GRASS wiki page at GRASS user wiki.

Merging to trunk policy

• single window GUI should be g.gui.* module placed in addons
  • Q: Is this now technicaly possible?
• duplicated code cannot be committed into trunk
• code in addons which duplicates code in trunk is tolerated as a temporal solution
• code which has to be changed in the trunk should be changed by a self-contained patches
  • changed means refactored in this case
  • it is critical that new code will work with the old GUI and the g.gui.* module in addons (this demonstrates also good code quality)
• only finished single window GUI which will not cause any code duplication can be committed into trunk

WIP

Background

After significant improvements of the Data Catalog ​https://trac.osgeo.org/grass/wiki/GSoC/2020/StartupWindow, which led to the creation of a new startup mechanism and the removal of the startup screen, another topic enhancing the user experience comes into consideration - the Single Window User Interface. All historical versions of GRASS can spread across multiple screens. It can be beneficial for some, but it can be a bit annoying as well, as almost every task generates a new wxGUI window freely floating around on the screen. Another lack with the current solution is that tabs in Layer Manager can cause trouble to new users. This issue was clearly evident from surveys among GRASS users where some of them did not record the Modules tab at all. The new design would therefore assume that all panels would be visible immediately after startup. The fact that the Single Window layout would really be appreciated by users can also be deduced from the surveys conducted in my master thesis ​lab-projects/dp-kladivova-2021/blob/master/text/linda-kladivova-dp-2021.pdf. Of course, especially long-term users can prefer the existing multi-layout way, so this original option will be retained. The single-window GUI will therefore be built "next to" the existing multi-layout GUI. As an example, the GIMP software works similarly. It also left the user the option to switch to multi-layout, but by default, it starts in a single-window layout.

State of Art in version 7.9 (Multiple Window Layout)

First, let's look at the current solution in version 7.9 (Spring 2021). GRASS GIS consists of two windows (frames) after launch - Layer Manager and Map Display. Additional maps can be opened as separate Map Display windows. Each Map Display window corresponds to the Map Display tab defining the visual content of a particular Map Display window.

GRASS GIS Layer Manager contains the Menu from the top, then three dockable toolbars Workspace, Tools, and Misc.

The most spatially extensive widget is a notebook, which in a standard 2D projection contains 5 tabs - Data, Display, Modules, Console, and Python. When switching to 3D projection, this number is increased by the 3D view tab.

In addition to the Data Catalog, the Data tab also contains the Data Catalog toolbar and the infobar object. Similarly, the Display tab now has its own group of buttons - Display toolbar. These tabs were created by moving some of the previously available buttons in the dockable toolbars at the top of the Layer Manager. Thus, in version 7.9, each tab forms a certain whole which will be further preserved for a single layout.

Proposal for Single Window Layout

The mock-up layout in Figure 4 is visually inspired by the layout in QGIS. Like QGIS or other GIS software, it contains a data catalog and layer catalog on the left, and a catalog of tools (modules) on the right.

The design is based on the wx.Aui.Manager class, which is the central class of the AUI class framework. In this class, we create so-called panes i.e. panels with docking and floating behavior (more ​https://wxpython.org/Phoenix/docs/html/wx.aui.AuiManager.html). wx.Aui.Manager is not a new concept in GRASS. As we can see in Figure 2, it is already used for creating dockable toolbars in the upper part of the Layer Manager and in the Map Display. These tabs, as well as the Menu bar at the top of the software, will remain the same as in version 7.9.

The designed Single Window Layout consists of 1 window, in the middle of which are Map Displays as notebook tabs. Each Map Display tab, therefore, represents a Map Display window, as we know it from version 7.9. It is not possible to move with a tab containing Map Displays (it is not dockable), but we can divide the space so that more maps can be seen at once (see Figure 5). Depending on which Map Display is active, the correct tab in the Display tab is selected and vice versa. Around the central map notebook, there are 5 dockable panes in a standard 2D projection - Data Catalog and Display on the left, Modules, Console, and Python on the right. When switching to 3D projection, this number is increased by the 3D view tab - which is displayed in the left part under the Display panel. Dockable panes can be pulled out and rearranged according to the user's own preferences. One example can be seen in Figure 6. Panes can only be maximized and minimized. The situation after minimizing all panes can be seen in Figure 7. Closing panes in the case of GRASS does not bring any special plus in my opinion - after closing it is usually hard to find and reopen the tab (hopefully the reader will tell me the truth :-)) and it would also involve the implementation of a check box mechanism to the menu bar as e.g. in QGIS. GRASS has most functionalities in the form of separate modules, which means that the number of tabs is a maximum of 6 (unlike QGIS having almost 20 tabs).

As I have mentioned above, each tab in version 7.9 forms a certain whole. The buttons in the Data Catalog toolbar in the Data tab are used to organize the data in this tab. Similarly, the Display tab has its own toolbar, which is used to add, delete, and further organize the layers displayed in Map Display. However, the disadvantage of this solution is that the Data Catalog toolbar and Display toolbar cannot be part of the respective panel in their original length, as they are too long. Therefore, there would have to be either placed horizontal toolbars on top of each other in the given panel or inserted one vertical toolbar on the left. Personally, I am more inclined to the option of creating two horizontal toolbars.

However, the implementation of a Single Window GUI does not only involve a widget reorganization. To reach a truly user-friendly result, it should be possible to switch to the original multi-layout. Then it would be also advantageous to have a button returning GRASS to the original Single Layout settings (useful in the situation when a user would significantly reorganize widgets and would not be able to go back). Both buttons related to the layout in GRASS GIS could be part of the new dockable Layout tab, which would be located next to the dockable Misc tab. A similar way of changing the layout using the buttons is implemented, for example, in the software jBEAM.

The third important function is the ability to remember the single-window layout for the next session as well as within the saved workspaces.

As part of the new single layout, it would also be good to reopen the question about tab (pane) names. The main GRASS GIS window is named Layer Manager, although in practice only the Display tab can be considered a Layer Manager. Similarly, in the surveys, the proposal was made to rename the Modules tab to Tools.

Single Window Layout Roadmap

• Refactoring: Creation of a separate class for workspace management (Layer Manager needs to be lightened).
• Refactoring: Creation of a separate file for the Display tab. Then the main script for creating a Layer Manager will no longer contain functions related to displaying layers in the Display tab. A separate file is also created for the Display toolbar.
• Refactoring: The main script together with the relevant toolbars will be moved to a new App directory. This means that the Layer Manager will take over the role of the Display tab. So we will have a new directory, which will be the parent for tabs (panes) and we will define a Single Layout in it.
• Refactoring: Creation of a separate function responsible for instantiating all five panels (Data, Display, Modules, Console, Python).
• Refactoring: Edit of functions related to creating notebook tabs for multi-layout. Applies to _createNoteBook, AddNvizTools, RemoveNVizTools, etc.
• Refactoring: Introduction of a new layout flag (variable) into the Layer Manager, so far it will be primarily set to multi-layout.
• Refactoring: Features related to adding and removing the 3D tab and 3D toolbar will be adapted to the future option - in the case of Single Layout the newly added panel is not added to the notebook but to the AUI pane. Similarly, other functions requiring to switch to the Display tab for their operation (for example, adding vector or raster data) will be adapted to the future variant using the "layout" flag.

• Single Layout: Defining a new Map Panel class whose instances will be elements of the new Map Display notebook pane.
• Single Layout: Defining an AuiManegerClass that will secure some general functions needed for Single Layout.
• Single Layout: Single layout AUI panes (input instances of Data, Display, Modules, Console, Python, Map Panel) will be created through a new function.
• Single Layout: Update of the guiparent changes after switching (for a multi-layout it is a notebook, for a single layout the main frame).
• Single Layout: Switching to the desired layout through a new Layout tab