wxGUI: display toolbar size too large

[neteler]

On my laptop, with a 1366x768 pixel screen, I am not able to see the entire display toolbar without overlapping the window with that of the map layer manager.

Attached a screenshot.

Proposed solution: split the already dockable toolbar into two toolbars so that the user can stack both parts on top of each other on smaller screens.

[neteler]

Overlapping windows, indications for an enhancement

[wenzeslaus]

Can you please take a screenshot with the 2D view/3D view/... selection active, i.e. with all the items visible? It seems that most of the space in the toolbar is taken by whitespace in that select box. For me (wxPython: 3.0.1.1) the select box is much much smaller and with digitizers, I don't see all the text when the mode is active. It also seems that the padding around the buttons is much bigger on your machine.

[martinl]

Replying to neteler:

Proposed solution: split the already dockable toolbar into two toolbars so that the user can stack both parts on top of each other on smaller screens.

the toolbar is too long, your proposal make sense to me.

[neteler]

How hard would it be to split the since toolbar into two toolbars as it already is in the Map Display window?

[neteler]

Ticket retargeted after milestone closed

[neteler]

Ticket retargeted after 7.0.3 milestone closed

[neteler]

Replying to neteler:

How hard would it be to split the since toolbar into two toolbars as it already is in the Map Display window?

... this would be really important to implment for a better user experience.

[wenzeslaus]

I think that splitting it into two parts would make it quite uncomfortable when moving the toolbar(s) out of the windows (you would have to fiddle with two instead of one). The handle at the beginning of the toolbar would make the whole toolbar longer. Putting into two rows is not really an option for small (all?) screens.

In r67699 I have removed the separators which I think were not necessary. This makes it one button shorter for me (which is not enough).

I suggest to remove Erase display and Print display buttons. I don't think they are that useful. Opinions?

Comparing to 70 branch, trunk has one more button which is Select vector feature(s). We also added zoom to region recently. Both should be definitively there but we should keep in mind that we've already hit the limit.

The biggest issue probably is the combo box with the different modes. I don't know why it is so big on the screenshot from Markus. There are no long entries in it in 70 (2D view, 3D view, Digitize). For me it is much smaller (even in trunk where there is Vector digitizer and Vector digitizer) but when the window is too small and the whole combo box wouldn't fit there, the combo box just disappears and there is an empty space instead. These both issues might be related to wxPython or the specific platform. However, the issue probably is that this combo box doesn't work well in a toolbar. Further research is needed to determine if there is some good replacement. For example, the normal toolbar buttons are grouped under one automatically for me when the window is really small (the string we use as internal label is shown as menu item).

[wenzeslaus]

Map Display toolbar with and without separators (trunk 67698 and r67699)

[wenzeslaus]

In r67700 I removed some toolbar separators in Layer Manager. Making lmgr smaller might be also a way. There is probably a reason why there is so many separate toolbars in the lmgr, but if we merge them, we would save some horizontal space (the toolbar handles look ugly anyway on many platforms: Win, Mac, Lubuntu).

However, there is some minimal size set now for lmgr. I assume that it is because of issue with hidden menu items on platforms which don't support some arrow or something to deal with long menus (#1742). But perhaps it is not a big issue anymore when we have quite usable Search modules tab.

[mlennert]

Replying to wenzeslaus:

I suggest to remove Erase display and Print display buttons. I don't think they are that useful. Opinions?

+1

Comparing to 70 branch, trunk has one more button which is Select vector feature(s). We also added zoom to region recently. Both should be definitively there but we should keep in mind that we've already hit the limit.

Although, I do find it an improvement in user experience, I wouldn't have any objection to move 'zoom to region' back into the zoom menu where it used to be if that is necessary.

[wenzeslaus]

r67699 (no separators in Map Display toolbar) backported in r67698 together with r67700.

With wxPython 3.0.2.0 on Ubuntu 15.10 with Unity, all the toolbar objects disappear one by one when the toolbar is too small for the whole object to fit. However, the standard toolbar buttons are still accessible through an arrow/triangle at the end of the toolbar in case they are hidden. The look is not really good but all the functionality is accessible including the buttons with submenu (e.g. Various zoom options) and buttons which switch with each other (e.g. Digitize area/boundary/centroid). However, this does not work for the other widgets like the combobox/choice which is used to switch the Map Display modes.

[wenzeslaus]

Replying to mlennert:

Replying to wenzeslaus:

I suggest to remove Erase display and Print display buttons. I don't think they are that useful. Opinions?

+1

r65774 and r67826 removed Display map, Erase display, and Print display buttons. The trunk toolbar is now 2 buttons shorter than the release branch toolbar.

Now, there is no way to invoke the Print display functionality, but I left the function there for now.

[wenzeslaus]

Map Display toolbar in trunk after r67826 and in release branch 70 after r67822 (r67699)

[veroandreo]

overlapping lmngr and map display plus shorter toolbar in map display

[veroandreo]

Replying to wenzeslaus:

r67699 (no separators in Map Display toolbar) backported in r67698 together with r67700.

With wxPython 3.0.2.0 on Ubuntu 15.10 with Unity, all the toolbar objects disappear one by one when the toolbar is too small for the whole object to fit. However, the standard toolbar buttons are still accessible through an arrow/triangle at the end of the toolbar in case they are hidden. The look is not really good but all the functionality is accessible including the buttons with submenu (e.g. Various zoom options) and buttons which switch with each other (e.g. Digitize area/boundary/centroid). However, this does not work for the other widgets like the combobox/choice which is used to switch the Map Display modes.

Under Fedora 23 (wxPython 3.0.2.0), though I can shrink the toolbar in Map Display and I see the behaviour you describe, I can no longer shrink the Map display window and therefore, it still overlaps with layer manager even if it is also shrunk until limit size allowed. Same thing happens in trunk (r67847) and release branch (r67848). My screen is also 1366x768. I attach a png file.

[wenzeslaus]

Replying to veroandreo:

Under Fedora 23 (wxPython 3.0.2.0)...I can no longer shrink the Map display window and therefore, it still overlaps with layer manager even if it is also shrunk until limit size allowed.

Since when you can't do it? I don't know about any changes in release branch in relation to that, so it would seem that it might be related to some wxPython changes. Also many of these problems are coming from wxPython itself or its interaction with underlying library, so what you can try is to download the ​wxPython demo, find same widget there and if it has the bad behavior, report the issue on the ​wxWidgets Trac (component wxPython).

It doesn't seem that Map Display is setting minimal size (SetMinSize) unlike for example Layer Manager window. I actually can make the window "one pixel" big with the same wxPython (wxPython: 3.0.2.0). I guess the question also is if you can shrink the other windows in that particular direction.

[wenzeslaus]

Possibly related: r68229

[martinl]

Can we close the ticket?

[veroandreo]

Replying to wenzeslaus:

Replying to veroandreo:

Under Fedora 23 (wxPython 3.0.2.0)...I can no longer shrink the Map display window and therefore, it still overlaps with layer manager even if it is also shrunk until limit size allowed.

Since when you can't do it? I don't know about any changes in release branch in relation to that, so it would seem that it might be related to some wxPython changes. Also many of these problems are coming from wxPython itself or its interaction with underlying library, so what you can try is to download the ​wxPython demo, find same widget there and if it has the bad behavior, report the issue on the ​wxWidgets Trac (component wxPython).

It doesn't seem that Map Display is setting minimal size (SetMinSize) unlike for example Layer Manager window. I actually can make the window "one pixel" big with the same wxPython (wxPython: 3.0.2.0). I guess the question also is if you can shrink the other windows in that particular direction.

The issue prevails here in 72 (r69220) and trunk (r69219) under fedora24. I cannot shrink map display window, nor the window for d.vect, for example. I am able to shrink in any direction the window of g.gui.tplot, though. No idea :P

[neteler]

Ticket retargeted after milestone closed

[martinl]

Still the issue?

[neteler]

Replying to martinl:

Still the issue?

Quickly tested on Fedora 26, to me it looks like solved. Closing.