WXGUI layer manager window doesn't show all menubar entries

[marisn]

When starting WXGUI in non-english language, Layer Manager window is too narrow to display all menubar entries.

Steps to reproduce:

• start WXGUI in German

Setting as blocker, as with German version there's not even a slightest hint that "Datenbank" and "Hilfe" entries are missing.

[marisn]

Screenshot of WXGUI Layer Manager with default configuration

[neteler]

I second this - this applies to many translations. (Obvious, sorry) suggestion: autocalculate the width of the window as it is already done in some wxGUI windows.

[wenzeslaus]

Replying to neteler:

(Obvious, sorry) suggestion: autocalculate the width of the window as it is already done in some wxGUI windows.

There is another problem which is connected to this one (probably obvious too). If you make Layer Manager window bigger (manually as a user or programmatically) on small monitors there will be not enough space to have Layer Manger and Map Display side by side unless you will make Map Display thinner (but then it will be not useful). I can see only one solution for that: One big window for layer manager's and map display's widgets (​GSoC ideas, wxGUI, point 3).

[annakrat]

Replying to neteler:

I second this - this applies to many translations. (Obvious, sorry) suggestion: autocalculate the width of the window as it is already done in some wxGUI windows.

I couldn't find a way to determine the menubar length, it always gives me only the width of the frame itself.

Is this really a blocker? It's the standard behaviour of wxWidgets. There is also some custom menu - wx.FlatMenu - however from the demo I can see that this problem is solved only for too long toolbar and not for the menu.

[martinl]

Replying to annakrat:

Is this really a blocker? It's the standard behaviour of wxWidgets. There is also some custom menu - wx.FlatMenu - however from the demo I can see that this problem is solved only for too long toolbar and not for the menu.

I can hardly agree with blocker status... Please change the priority to be more realistic, otherwise we will never release 6.4.3.

[wenzeslaus]

Replying to martinl:

Replying to annakrat:

Is this really a blocker? It's the standard behaviour of wxWidgets. There is also some custom menu - wx.FlatMenu - however from the demo I can see that this problem is solved only for too long toolbar and not for the menu.

I can hardly agree with blocker status... Please change the priority to be more realistic, otherwise we will never release 6.4.3.

For Ubuntu 12.04 (with Unity) it is definitively not a blocker considering ​global menu bar and ​HUD.

[martinl]

Downgrading priority...

[martinl]

Replying to martinl:

I can hardly agree with blocker status... Please change the priority to be more realistic, otherwise we will never release 6.4.3.

Also note that on Windows the menu is automatically wrapped.

[wenzeslaus]

Although the long menu is unpleasant and we want to solve this problem, it is not planed to solve it for 6.4.*. Currently only ideas how to solve this problem are:

• one big single (​http://trac.osgeo.org/grass/wiki/wxGUIDevelopment/SingleWindow) window
• or toolboxes and thus possibly shorter menu (​http://grasswiki.osgeo.org/wiki/Toolboxes, probably ​http://trac.osgeo.org/grass/wiki/wxGUIDevelopment/Toolboxes in the future).

Both ideas are valid only for 7. Moreover, for MS Windows (with wrapped menu), Mac and Ubuntu with Unity (with global menu) it is not such a critical problem.

So, changing milestone to 7.0.0 (i.e., for 6.4.3 it is closed as wontfix).

[neteler]

Replying to marisn:

When starting WXGUI in non-english language, Layer Manager window is too narrow to display all menubar entries.

On Windows8 this is no longer the case, the menu is being wrapped to to lines.

[wenzeslaus]

This is not going to be fixed soon, especially if it affects only some systems and some languages, so for now I just recap solutions.

Possible solutions

Fix the system library

• fix the system GUI library
• we can say that the system library handles long menus in the wrong way (hides items withou notifying a user)
• hidden items itself are in fact not problem of GRASS but of the system GUI library (maybe it is a problem of wxPython/wxWidgets but probably not)

Single window GUI

• redesign the wxGUI to big single window which can have a long menu
• this would solve it, but we still want to have current multi window GUI and for this the problem would be still present

Bigger Layer Manager window

• make Layer Manager window bigger
• no point in this, width is needed for menubar (and toolbars) but usually not for the content itself

Abbreviations

• use abbreviations in the menu (in English? in translations? optionally?)

Shorter menu

• create a shorter menu (but what shall be omitted?)
• create a shorter menu using toolboxes for yourself
  • possible now, see ​user manual page
  • only workaround, each affected user must do it

[hamish]

Hi,

some 2c comments:

• IMO abbreviations should be avoided in almost all situations. the learning curve and new jargon is hard enough to decipher already, especially for non-native speakers trying to figure out what a 4-5 letter non-word is supposed to mean.

• re. looks ok on Unity: it's one window manager among many, in one distro among many, of one operating system among several. Maybe it has a big market share for us, but I wouldn't think to design anything around it or suggest it to anyone as a solution to the menu error.

• it's important. we should make it work on all languages. ("missing" tabs in module guis is another related issue, the filled triangle is hard to see)

• my vote for a quick fix is to start by making the layer manager starting width a bit bigger (module guis too). (also good for the output window/tab) see also ctrl-t tile window wish/patch: #2004

• Please, for the love of all that is good an right in the world: don't name the personal menu as "My Favorites". Anything but that. (mmph, "Custom"?)

thanks, Hamish

[wenzeslaus]

Replying to hamish:

abbreviations... Unity...

Agreed.

("missing" tabs in module guis is another related issue, the filled triangle is hard to see)

This is reported in #306 and should be improved (or even fixed) by r52927, maybe we need to change the default settings now.

my vote for a quick fix is to start by making the layer manager starting width a bit bigger.

it's important. we should make it work on all languages.

Unfortunately, there is always some language with extreme word-length. But yes, we can try to set the width e.g., for German, but, as I noted earlier, I'm afraid that this will create too big layer manager window (I think I've already tried).

[wenzeslaus]

Possible solutions

update for comment:10

Shorter menu

Toolboxes XMLs now (after r57187, r57188 and r57199) provide possibility to have different tree for main menu bar and for the module tree in module search tab. It is not yet in documentation but it's the same as previous version but now there are two files (main_menu and module_tree) used by GUI.

We can reduce the number of main entries in main menu: remove Database, Imagery or Volumes item because they are in the module tree. This is a change in philosophy of wxGUI of course. However, it's no so big because Temporal (framework) item was newer in the menu, it's only in the module tree (the same applies also for special Addons and Custom toolboxes items).

[cmbarton]

This wish/issue has been around since the TclTk menus. The screenshot attached shows what appears to be a low resolution, small monitor, creating a small layer manager with large type. This is exacerbated by long menu entries in German. I agree with Hamish that while we definitely want GRASS to work across multiple languages, we should not make the interface worse for the majority to satisfy a minority of users. So we need to understand the true extent of this problem. So here are a few questions and comments.

1. The current menu words in English were picked because they were relatively short. Rather than direct translation to another language, can the same concepts be expressed in shorter words? It is the concepts that are important, not the actual words used in the menus. This is something those who work on the translations can best consider and answer.

2. On the smaller monitor of my MacBook Air, the absolute (i.e., in mm) size of the type is smaller because more pixels are crammed into smaller screen real estate. Is this primarily a problem on small monitors with average or lower resolutions (e.g., notebook computers)?

If so, we need to think about whether this is the main GRASS user audience. While it would be nice to run GRASS on a notebook (and a number of student do so here) those platforms are not really very good for GIS work. While it is really great that GRASS works on such platforms, I'm reluctant to optimize the GUI for such platforms.

The menu structure (horizontal menu bar, pull down menu item lists, sub-menus) is very traditional. However, this in and of itself tends to be best at optimizing limited screen real estate (i.e, small displays). A top level list of menu items can be horizontal, vertical, or in a rectangular matrix. All current displays are longer horizontally than they are vertically. So, especially for long words, you can get more textual information while using up less available screen space in a horizontal menu than in either of the other 2 options, because each menu entry only takes up the width of the menu word. For a vertical set of menus, each entry takes up the space of the longest word in the entire menu. Block matrices are similarly affected.

One solution is to allow the user to alter the menu font size in the preferences. It could then be set for different display environments by the user. Another solution is to replace the words in the top level menu with more icons. The possible draw back is that icons may not be easily understandable to novice users (see below). But with mouse over text, they can be learned relatively easily.

3. Currently, it is relatively easy to find and access all functions in GRASS--in spite of the fact that it is a very complex program with hundreds of modules--because of the current menu design. Early in the current GUI design process, one of the devs (I don't remember which one) noted that good menu design should keep all selections within a maximum of 3 levels of nesting (top menu, pull-down, and sub-menu). This has been a very good principle to follow. One of the complaints I regularly hear about Arc is how difficult it is to find different functions, being nested in menus, leading to tool boxes, leading to dialogs and more menus.

The current GUI attempts to group functions according to work flow. Functions for making and altering maps are in the menus, functions for arranging maps for viewing are in the layer manager. Functions for interacting with displayed maps are in the map display windows. I'm in favor of experimenting with new designs for ways to access different functions. But the top priorities in any GUI should be ease of access, transparency in signaling, and facilitating work flows. Users should be able to find and identify the tools they need as quickly and as easily as possible as they need them. So I remain skeptical of tool boxes and don't like the idea that users will need to access yet another interface (e.g., hierarchical module list) from the primary interface to find a needed function. As much as possible should be accessible at a glance, while minimizing the loss of total screen space--which is best used to display maps.

These are just some musings. We need to be innovative but for the GUI keep in mind novice rather than expert users.

[wenzeslaus]

Patch to adjust lmgr frame minimal width according to ideal menu width

[wenzeslaus]

I added a patch to adjust lmgr frame minimal width according to ideal menu width (attachment:lmgr_width_for_menu.diff​).

But:

• it adjusts minimal size, not the real size, so user cannot make lmgr frame smaller; implement it for the (non-minimal) size is difficult (there are default values and user settings involved)
• width is only estimated, I put there some magic constants which worked for en, cs and de on Ubuntu
• it should do nothing for English but the locale test fails on some PCs returning None; locale is always fragile

It is too complex I think and I'm now not sure if it was worth to even try to write this patch, but since it is written I posted it here.

[wenzeslaus]

Hamish wrote on ML ([GRASS-dev] GRASS GIS 7 tech-preview release preparations):

I welcome better presentation of the menus since they get rather big (platoon rule of thumb: any more than ~12 in any level/group gets a bit overwhelming), but wrt "search to run" as the primary instead of augmenting method, I fear that way is not very discoverable -- at least I'd like to avoid the situation where a new user needs to know the name of what they're looking for before they can find it, which isn't so good to explore & learn about new modules you don't know exist yet. Especially for a software so big as ours which takes years to fully know.

Look at the 'Search modules' in lmgr. There is a search box but also a tree which you can browse.

We are spatial creatures, so a spatial model for menu layout where we can use our spatial & muscle memories helps I think. Our monitors are getting really wide these days, both desktop and laptop, and so top menu bars will fit even better than they used to, we just have to make the windows a bit wider to compensate. Luckily these days there's space for that. (2c)

Bit wider is not enough for German, it has to be much bigger.

[wenzeslaus]

I've committed a wider lmgr in r57518. It does nothing for MS Windows, Mac OS X and Ubuntu with Unity (UBUNTU_MENUPROXY properly set).

It does nothing if you have some settings, so mv .grass7 .grass7.1 to test this.

I'm don't like it because for English it creates bigger lmgr than needed (on the other platforms) and it is far from being general language-independent. But yes, user can and probably will change it in the settings (save current win layout), but this was possible before the change, too.

We can change the constant if needed. It works for German and Ubuntu without global menu.

If this is what we want, close the ticked. If it is not, revert r57518.

[cmbarton]

Replying to wenzeslaus:

Hamish wrote on ML ([GRASS-dev] GRASS GIS 7 tech-preview release preparations):

I welcome better presentation of the menus since they get rather big (platoon rule of thumb: any more than ~12 in any level/group gets a bit overwhelming), but wrt "search to run" as the primary instead of augmenting method, I fear that way is not very discoverable -- at least I'd like to avoid the situation where a new user needs to know the name of what they're looking for before they can find it, which isn't so good to explore & learn about new modules you don't know exist yet. Especially for a software so big as ours which takes years to fully know.

Look at the 'Search modules' in lmgr. There is a search box but also a tree which you can browse.

We are spatial creatures, so a spatial model for menu layout where we can use our spatial & muscle memories helps I think. Our monitors are getting really wide these days, both desktop and laptop, and so top menu bars will fit even better than they used to, we just have to make the windows a bit wider to compensate. Luckily these days there's space for that. (2c)

Bit wider is not enough for German, it has to be much bigger.

I can make the window MUCH wider if I want and then save it so that it opens that wide every time I start the GUI afterwards. So I'm not sure I understand the problem. It seems that the issue is a combination of having long words for menu headings, small displays, and low resolution. Or do I misunderstand? If this is the crux of it, I'm not convinced that we should rework the entire GUI for all other GRASS users in order to deal with that specific problem.

[mlennert]

Replying to wenzeslaus:

I've committed a wider lmgr in r57518.

I can confirm that this creates a nicer initial contact for French-speaking users as you can now see all menus at startup. +1 for keeping this patch.

A similar issue (but maybe for a separate ticket): the wxdigitizer in the map display has a row of buttons that is too long for the map display, hiding the 'exit' button that I find quite essential. If one does not know that it exists, there is not indication for the user to look for it...

Moritz

[wenzeslaus]

map display with vector digitizer (exit button visible, default size, original screenshot 802x629)

[wenzeslaus]

Replying to mlennert:

Replying to wenzeslaus:

I've committed a wider lmgr in r57518.

I can confirm that this creates a nicer initial contact for French-speaking users as you can now see all menus at startup. +1 for keeping this patch.

It is in code for 4 moths without complains about side effects, solution works, so closing the ticket as fixed.

A similar issue (but maybe for a separate ticket): the wxdigitizer in the map display has a row of buttons that is too long for the map display, hiding the 'exit' button that I find quite essential. If one does not know that it exists, there is not indication for the user to look for it...

This is the same problem system or wx toolbar which we cannot change and we have only limited space on screen. We could enlarge Map Display but we already enlarged Layer Manger, so on a small screen they fight each other for space.

Create a separate ticket (and link this one) if it is an issue for you. However, I cannot fully confirm. The default (when you haven't saved the windows positions to user settings) is defined by (in globalvar):

MAP_WINDOW_SIZE = (800, 600)

On my computer when opening a GUI for the first time (e.g. after removing the .grass7 directory), I get the map window large enough (see attachment). The original size of the screenshot (and probably of the window) was 802x629. However, I can resize the window, so that I cannot see the exit button anymore, so this is the way how to get to your situation. But I'm not sure, enforcing minimal size would be a solution but so far I saw that flexible map display has its advantages.