wxGUI: Move statusbar checkboxes related to Map Display to a new Map Display Settings dialog

[lindakarlovska]

This is the starting point of changes that are gonna lead to complete statusbar combobox removal.

I am creating the new Map Display Settings here, accessible from the map display toolbar and move there four statusbar checkbox items - autoRendering, AlignExtent, Resolution and ShowRegion. I have not moved the last checkbox related to the Projection shown in the status bar since it is more complex and needs the special PR.

For above-described purpose, a new file mapdisp/settings.py has been proposed. Here we can prepare checkbox items (and other needed widgets) and then fill the new Map Display settings dialog.

Please feel free to discuss!

• We need to think about the Map Display base class. I used PreferencesBaseDialog but I am not sure how the "Set to default" option should work. When I tried it in General Settings, I discovered that this option does not work even there, so I have set up the Issue: [Bug] wxGUI: Set to default in GUI settings does not work #2032.

• Second thing is the Map Display Settings icon. I have used the base Settings icon from General settings, but it is not final solution. Probably only changing the color is not the solution either as commented here [Feat] wxGUI: Redesigning Map Display status bar combo box into a new Map Display Settings dialog #2017. ..

Might be other things, also the form of Map Display settings is an important question, for more info please see #2017.

[petrasovaa]

Shouldn't this be a signal?

[lindakarlovska]

Actually, it is a signal, and is returned in the child property. But you are right that we do not need any mapFrame dependency. I have got rid of it.

[petrasovaa]

Ideally, they shouldn't know about mapFrame and use signals or so.

[lindakarlovska]

Ok, I've incorporated giface..

[petrasovaa]

This probably shouldn't be private when you provide a setter. Or remove the setter.

[lindakarlovska]

@petrasovaa Save button and Set to default do not work so far, I am working on it. :-)

[lindakarlovska]

We need to think carefully about the Map Display Settings icon. We could use some from QGIS:
e.g.
https://github.com/qgis/QGIS/blob/master/images/themes/default/mActionMapSettings.svg or
https://github.com/qgis/QGIS/blob/master/images/themes/default/mActionOptions.svg
or I would prefer to create the new one and apply the https://github.com/OSGeo/grass/blob/main/gui/icons/grass/map-settings.png settings theme on the monitor icon (https://github.com/OSGeo/grass/blob/main/gui/icons/grass/monitor-create.png). Any opinions on that?

[petrasovaa]

Overall, I expected fewer changes. It looks like the SbItem-derived classes could be minimally adjusted and just work. The Python properties are not useful here, maybe except mapWindowProperty, they just blow out the code. Also, using underscore means the attribute is private, so you are not supposed to access it from outside (so property doesn't make sense).

I would first keep the statusbar.py untouched, they are used in other standalone map displays.

[petrasovaa]

We need to think carefully about the Map Display Settings icon. We could use some from QGIS: e.g. https://github.com/qgis/QGIS/blob/master/images/themes/default/mActionMapSettings.svg or https://github.com/qgis/QGIS/blob/master/images/themes/default/mActionOptions.svg or I would prefer to create the new one and apply the https://github.com/OSGeo/grass/blob/main/gui/icons/grass/map-settings.png settings theme on the monitor icon (https://github.com/OSGeo/grass/blob/main/gui/icons/grass/monitor-create.png). Any opinions on that?

No strong opinion here, I am fine with the same icon, or perhaps the last solution you suggest.

[lindakarlovska]

Overall, I expected fewer changes. It looks like the SbItem-derived classes could be minimally adjusted and just work. The Python properties are not useful here, maybe except mapWindowProperty, they just blow out the code. Also, using underscore means the attribute is private, so you are not supposed to access it from outside (so property doesn't make sense).

Ok, I will preserve just mapWindowProperty.

I would first keep the statusbar.py untouched, they are used in other standalone map displays.

Ou, you are right. I have not realized that. But I would keep the ChBRender in settings.py because it has the same form as other checkboxes and I think it is more clear to have it together with settings. We might also want to have the auto-render checkbox in Map Display settings.

[lindakarlovska]

Overall, I expected fewer changes. It looks like the SbItem-derived classes could be minimally adjusted and just work. The Python properties are not useful here, maybe except mapWindowProperty, they just blow out the code. Also, using underscore means the attribute is private, so you are not supposed to access it from outside (so property doesn't make sense).

Ok, I will preserve just mapWindowProperty.

I would first keep the statusbar.py untouched, they are used in other standalone map displays.

Ou, you are right. I have not realized that. But I would keep the ChBRender in settings.py because it has the same form as other checkboxes and I think it is more clear to have it together with settings. We might also want to have the auto-render checkbox in Map Display settings.

Mmmm as I think about it, I let the statusbar.py entirely as it was - it is probably the best solution now even though we duplicate the code.

[petrasovaa]

@petrasovaa Save button and Set to default do not work so far, I am working on it. :-)

I don't think that's what we want. It should behave the same way as the widgets in statusbar, so when you check it, it immediately changes the property. No save buttons there. Set to default may make sense but is perhaps not needed.

[lindakarlovska]

We have only one button Close now, so the way how it works is the same as in the status bar - just local settings.

[petrasovaa]

The tooltips don't work because the checkbox is not a child of the staticbox, so either remove the staticbox or change the parent of the checkboxes. Perhaps the staticbox might not be needed here.

[lindakarlovska]

The tooltips don't work because the checkbox is not a child of the staticbox, so either remove the staticbox or change the parent of the checkboxes. Perhaps the staticbox might not be needed here.

I would keep the Customize Map Display static box because there is the second static box below for Customize status bar with radio buttons planned. So, it would be better to change parent of the checkboxes.

[petrasovaa]

The tooltips don't work because the checkbox is not a child of the staticbox, so either remove the staticbox or change the parent of the checkboxes. Perhaps the staticbox might not be needed here.

I would keep the Customize Map Display static box because there is the second static box below for Customize status bar with radio buttons planned. So, it would be better to change parent of the checkboxes.

So what are the tabs for then?

[lindakarlovska]

@petrasovaa

The tooltips don't work because the checkbox is not a child of the staticbox, so either remove the staticbox or change the parent of the checkboxes. Perhaps the staticbox might not be needed here.

I would keep the Customize Map Display static box because there is the second static box below for Customize status bar with radio buttons planned. So, it would be better to change parent of the checkboxes.

So what are the tabs for then?

It is prepared for the Projection settings. You wrote: Regarding the projection, I would remove it from general settings altogether. So you had the notion that the Projection page will be entirely removed from the whole GRASS or just from GUI settings?

I had the feeling from our video call with you, Vashek and Martin that we plan to have a Projection page in Map Display settings (which sets a status bar CRS) and also mentions a global location coordinate system because it is something not visible anywhere and this place would be suitable. But maybe I understand it wrong.

Or maybe you thought that the Projection page in Map Display settings would be actually the Status bar page and we would have the radio buttons for status bar settings here and also the status bar projection. And maybe the global location projection could then be a part of the Map Display page. Probably this paragraph is a better option, or what did (do) you think?

[petrasovaa]

Or maybe you thought that the Projection page in Map Display settings would be actually the Status bar page and we would have the radio buttons for status bar settings here and also the status bar projection

I din't think about it too much yet, but perhaps this would make most sense.

And maybe the global location projection could then be a part of the Map Display page.

Not quite sure what you mean here.

[lindakarlovska]

Or maybe you thought that the Projection page in Map Display settings would be actually the Status bar page and we would have the radio buttons for status bar settings here and also the status bar projection

I din't think about it too much yet, but perhaps this would make most sense.

Good, then I will remove the static box widget and keep the notebook prepared for the Status bar page :-).

And maybe the global location projection could then be a part of the Map Display page.

Not quite sure what you mean here.

I mean that somebody set the CRS e.g. 5514 and then forgot what CRS he set. So, the Map Display settings dialog is, in my opinion, a good place to show it. Just as a non-editable text widget. There were also suggestions in the surveys that users would assume that they read the set CRS somewhere. They mentioned two ways - adding it in the context menu in Location tree mode (probably something like the Info context menu option) or directly as a part of the Location node text. But I think that for the beginning it would be also helpful to add it to Map Display settings.

[lindakarlovska]

Now it looks as follows:

[petrasovaa]

I would at this point remove the checkboxes from the map Display statusbar.

[lindakarlovska]

Now it looks as follows:

After changes, it looks exactly the same.

[petrasovaa]

Almost there! Maybe also make the dialog smaller, we can enlarge it once we need it.

[petrasovaa]

I just noticed the settings here but the file is named preferences.py. I would perhaps go with settings here (not strong opinion), so please rename the class as well.

[lindakarlovska]

Well, I changed it to preferences.py because in gui_core it is also called preferences.py. But anyway, settings.py could be anything (very general), I think preferences.py more points on the purpose. I would let it as it is, and change just the @Package name if it okey. :-)

[petrasovaa]

I guess my point was to avoid preferences, because that's used for something else, this is not actually setting any preferences, you changing the actual behavior for specific mp display. Settings is used elsewhere, so that may not be the right choice either. How about rename this to properties.py and use property for naming of the classes, because that's the terminology we use for this already?

[lindakarlovska]

Right, I think properties are better than preferences. Good idea! :-)

[lindakarlovska]

Almost there! Maybe also make the dialog smaller, we can enlarge it once we need it.

Yes :-)

[lindakarlovska]

I have noticed one thing and have not succeeded to find the solution. When you open the dialog for the second time (or any other time) it is smaller (a bit shrank). And the self.GetBestSize() is different. Probably not too important but I am just trying to figure out why it is like that...

[petrasovaa]

I have noticed one thing and have not succeeded to find the solution. When you open the dialog for the second time (or any other time) it is smaller (a bit shrank). And the self.GetBestSize() is different. Probably not too important but I am just trying to figure out why it is like that...

Hard to say, sizing is always a pain... You can try not using scrolled panel, that could simplify the problem little bit.

[lindakarlovska]

I have noticed one thing and have not succeeded to find the solution. When you open the dialog for the second time (or any other time) it is smaller (a bit shrank). And the self.GetBestSize() is different. Probably not too important but I am just trying to figure out why it is like that...

Hard to say, sizing is always a pain... You can try not using scrolled panel, that could simplify the problem little bit.

It did the same but maybe worse because theres no scrolling so it is a bit cut off. Generally I think it is rather a detail and when I make a dialog a bit bigger in terms of the height I think nobody will notice. What do you think? I could set up the height of 250.