wxGUI: Single-Window GUI: arrangement of basic widgets #1621

lindakarlovska · 2021-06-05T18:26:24Z

This PR deals with the base settings for the full screen layout with main dockable panes.
Map Displays as well as 3D view are not solved in this PR - we just need to prepare the base structure here.

There are two main things that we need to figure out:

Any content "not dockable" pane is necessary in terms of implementation. So first we need to decide whether to employ Data Catalog as the content pane. The advantage is that all other panes would be dockable then. :-) And also after changes made last year the Data Catalog is kind of the center point of GRASS so it could make sense to have it as the content pane. The con is that visually it might look a bit strange. There the layout I suggest so far in this PR (using wx.AUI):

Second important thing is to decide which library to use. We have two options: the traditional wx.AUI C++ library and the newer wx.lib.agw.aui python library. I tried to compared them a bit. There is a bit strange thing about wx.AUI -> MinimizeButton method does not work to me although according to https://wxpython.org/Phoenix/docs/html/wx.aui.AuiPaneInfo.html#wx.aui.AuiPaneInfo.MinimizeButton documentation, it should work. :-( The second thing I have come up with so far is the missing guide docking styles such as nice aui.AUI_MGR_WHIDBEY_DOCKING_GUIDES style.
Both of these functions work for wx.lib.agw.aui.

But there may be (and probably are) more things that are not implemented for wx.AUI. But I think we do not have to make the decision about the library right now.

…uff, widget sizes hardcoded

petrasovaa · 2021-06-06T02:47:42Z

gui/wxpython/main_window/frame.py

+        self.CreateMenuBar()
+        self.CreateStatusBar(number=1)
+        self.BuildPanes()
+        self.BuildEvents()


change to BindEvents

petrasovaa · 2021-06-06T03:32:41Z

Second important thing is to decide which library to use. We have two options: the traditional wx.AUI C++ library and the newer wx.lib.agw.aui python library. I tried to compared them a bit. There is a bit strange thing about wx.AUI -> MinimizeButton

I am leaning now towards the agw one since the wxWidgets one seems to be quite limited for our use case. For example we would like to have the option to group Modules, Data and Display into one side notebook widget, which you can do only with agw.

veroandreo · 2021-06-07T14:14:44Z

This PR deals with the base settings for the full screen layout with main dockable panes.
Map Displays as well as 3D view are not solved in this PR - we just need to prepare the base structure here.

There are two main things that we need to figure out:
* Any content "not dockable" pane is necessary in terms of implementation. So first we need to decide whether to employ Data Catalog as the content pane.  The advantage is that all other panes would be dockable then. :-) And also after changes made last year the Data Catalog is kind of the center point of GRASS so it could make sense to have it as the content  pane. The con is that visually it might look a bit strange. There the layout I suggest so far in this PR (using wx.AUI):

This looks really cool! Where will the layer tab go? Is it possible to put it below the data catalog similar to QGIS?

lindakarlovska · 2021-06-08T06:34:40Z

This PR deals with the base settings for the full screen layout with main dockable panes.
Map Displays as well as 3D view are not solved in this PR - we just need to prepare the base structure here.
There are two main things that we need to figure out:
* Any content "not dockable" pane is necessary in terms of implementation. So first we need to decide whether to employ Data Catalog as the content pane.  The advantage is that all other panes would be dockable then. :-) And also after changes made last year the Data Catalog is kind of the center point of GRASS so it could make sense to have it as the content  pane. The con is that visually it might look a bit strange. There the layout I suggest so far in this PR (using wx.AUI):
This looks really cool! Where will the layer tab go? Is it possible to put it below the data catalog similar to QGIS?

Yes, we can make it as I suggested here: (1) .
But I cannot decide which panel should take the role of the Content pane (non-dockable pane). I think it would be nice to have the Single-Window GUI where we can reach the Multi-Window GUI as well (only by pulling out Map Displays). In (1) we cannot do that because the notebook containing all Map Displays has the role of the Content pane.

So we need to either use the Data Catalog as the Content pane (as this PR suggests) - then all Map Displays will be dockable, or we could use the first opened Map Display as the Content pane and all other Map Displays except the first one will be dockable - this means, however, allowing the user to change it, e.g. suddenly a user wants to place the first Map Display on the second monitor, so he/she changes some settings and the first Map Display become dockable while the second Map Display becomes the Content pane.

I would add that people are already used to have some data organization and layer management on the left side and tools on the right side, so I would keep the arrangement in (1). And also having the Map Display in the center looks impressive. :-) Any suggestions about that?

Which idea regarding the Content pane you like more @veroandreo? Do you have any other ideas?

(1) https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopment/SingleWindow/single_window_layout.png

veroandreo · 2021-06-08T12:39:21Z

This looks really cool! Where will the layer tab go? Is it possible to put it below the data catalog similar to QGIS?

Yes, we can make it as I suggested here: (1) .

Yes, that one I like, so user can have control of layer properties

But I cannot decide which panel should take the role of the Content pane (non-dockable pane). I think it would be nice to have the Single-Window GUI where we can reach the Multi-Window GUI as well (only by pulling out Map Displays). In (1) we cannot do that because the notebook containing all Map Displays has the role of the Content pane.

Ok, I see. Indeed, it'd be nice to be able to switch to multiple window by pulling the maps, seems intuitive. However, just to confirm, would having the data catalog as content pane as in the fig above, still allow to place the layer manager below the data catalog as in (1)? If yes, that's perfect. I think placing the layer manager below data catalog is kinda natural, so the user has full control of layers, all in the same side of the screen (this is what I prefer, at least)

So we need to either use the Data Catalog as the Content pane (as this PR suggests) - then all Map Displays will be dockable, or we could use the first opened Map Display as the Content pane and all other Map Displays except the first one will be dockable - this means, however, allowing the user to change it, e.g. suddenly a user wants to place the first Map Display on the second monitor, so he/she changes some settings and the first Map Display become dockable while the second Map Display becomes the Content pane.

So using the map display as content pane would not allow to go back to multiple window layout as we have now, because one of them would always stay as content pane, right?

I would add that people are already used to have some data organization and layer management on the left side and tools on the right side, so I would keep the arrangement in (1). And also having the Map Display in the center looks impressive. :-) Any suggestions about that?

Which idea regarding the Content pane you like more @veroandreo? Do you have any other ideas?

I'm with you there! I love the layout in (1) ! This is my preferred one. In my personal use, indeed, I'd remove all those dockable panes on the right and only keep data catalog + layer manager (as in 1) on the left, and map display(s) over the rest of the screen :)

(1) https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopment/SingleWindow/single_window_layout.png

mlennert · 2021-06-08T13:30:10Z

Am 08.06.2021 14:39 schrieb Veronica Andreo:

>> This looks really cool! Where will the _layer_ tab go? Is it >> possible to put it below the data catalog similar to QGIS? > > Yes, we can make it as I suggested here: (1) . Yes, that one I like, so user can have control of layer properties > But I cannot decide which panel should take the role of the Content > pane (non-dockable pane). I think it would be nice to have the > Single-Window GUI where we can reach the Multi-Window GUI as well > (only by pulling out Map Displays). In (1) we cannot do that because > the notebook containing all Map Displays has the role of the Content > pane. Ok, I see. Indeed, it'd be nice to be able to switch to multiple window by pulling the maps, seems intuitive. However, just to confirm, would having the data catalog as content pane as in the fig above, still allow to place the layer manager below the data catalog as in (1)? If yes, that's perfect. I think placing the layer manager below data catalog is kinda natural, so the user has full control of layers, all in the same side of the screen (this is what I prefer, at least) > So we need to either use THE DATA CATALOG AS THE CONTENT PANE (as > this PR suggests) - then all Map Displays will be dockable, or we > could use THE FIRST OPENED MAP DISPLAY AS THE CONTENT PANE and all > other Map Displays except the first one will be dockable - this > means, however, allowing the user to change it, e.g. suddenly a user > wants to place the first Map Display on the second monitor, so > he/she changes some settings and the first Map Display become > dockable while the second Map Display becomes the Content pane. So using the map display as content pane would not allow to go back to multiple window layout as we have now, because one of them would always stay as content pane, right? > I would add that people are already used to have some data > organization and layer management on the left side and tools on the > right side, so I would keep the arrangement in (1). And also having > the Map Display in the center looks impressive. :-) Any suggestions > about that? > > Which idea regarding the Content pane you like more @veroandreo [1]? > Do you have any other ideas? I'm with you there! I love the layout in (1) ! This is my preferred one. In my personal use, indeed, I'd remove all those dockable panes on the right and only keep data catalog + layer manager (as in 1) on the left, and map display(s) over the rest of the screen :)

+1 also from me for Data catalog as content pane.

lindakarlovska · 2021-06-09T15:16:19Z

This looks really cool! Where will the layer tab go? Is it possible to put it below the data catalog similar to QGIS?

Yes, we can make it as I suggested here: (1) .

Yes, that one I like, so user can have control of layer properties

But I cannot decide which panel should take the role of the Content pane (non-dockable pane). I think it would be nice to have the Single-Window GUI where we can reach the Multi-Window GUI as well (only by pulling out Map Displays). In (1) we cannot do that because the notebook containing all Map Displays has the role of the Content pane.

Ok, I see. Indeed, it'd be nice to be able to switch to multiple window by pulling the maps, seems intuitive. However, just to confirm, would having the data catalog as content pane as in the fig above, still allow to place the layer manager below the data catalog as in (1)? If yes, that's perfect. I think placing the layer manager below data catalog is kinda natural, so the user has full control of layers, all in the same side of the screen (this is what I prefer, at least)

So we need to either use the Data Catalog as the Content pane (as this PR suggests) - then all Map Displays will be dockable, or we could use the first opened Map Display as the Content pane and all other Map Displays except the first one will be dockable - this means, however, allowing the user to change it, e.g. suddenly a user wants to place the first Map Display on the second monitor, so he/she changes some settings and the first Map Display become dockable while the second Map Display becomes the Content pane.

So using the map display as content pane would not allow to go back to multiple window layout as we have now, because one of them would always stay as content pane, right?

I would add that people are already used to have some data organization and layer management on the left side and tools on the right side, so I would keep the arrangement in (1). And also having the Map Display in the center looks impressive. :-) Any suggestions about that?
Which idea regarding the Content pane you like more @veroandreo? Do you have any other ideas?

I'm with you there! I love the layout in (1) ! This is my preferred one. In my personal use, indeed, I'd remove all those dockable panes on the right and only keep data catalog + layer manager (as in 1) on the left, and map display(s) over the rest of the screen :)

(1) https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopment/SingleWindow/single_window_layout.png

…coded sizes

lindakarlovska · 2021-06-10T07:31:37Z

I first thought that we could employ the Data Catalog as the content pane but it is not possible since we need the Data Catalog to occupy only the small part of the window but the Best Size settings do not work for the center pane. :-( It means that the Center pane always adapts and extends according to other widgets. That would not be good:

In yesterday's video call, we decided to use the Map Display as the Content pane instead. We can either follow the first layout proposal where Map Displays are in notebooks. There is a nice functionality that the notebook can be split so that we can see several Map Displays side by side as I suggested in the mock-up...:

Or we would have one center Map Display and each extra Map Display could be launched as a separate window as we know from the current solution - here we could utilize the second monitor.

So in this PR I proposed the basic skeleton and the Map Display content pane is left blank:

Regarding Map Display, we also need to have it in the form of wx.Panel (not only wx.Frame as now) and it is the task for the next PR.

veroandreo · 2021-06-10T19:16:33Z

I first thought that we could employ the Data Catalog as the content pane but it is not possible since we need the Data Catalog to occupy only the small part of the window but the Best Size settings do not work for the center pane. :-( It means that the Center pane always adapts and extends according to other widgets. That would not be good:

In yesterday's video call, we decided to use the Map Display as the Content pane instead. We can either follow the first layout proposal where Map Displays are in notebooks. There is a nice functionality that the notebook can be split so that we can see several Map Displays side by side as I suggested in the mock-up...:

Will we be able to collapse several map displays as tabs too as the tabs in the display pane in the mock-up? (I lack the right vocabulary, sorry)

petrasovaa · 2021-06-11T03:25:32Z

gui/wxpython/main_window/frame.py

-                .BestSize((self.toolbars[toolbar].GetBestSize())),
-            )
+        # set pane sizes according to the full screen size
+        self.PANE_BEST_SIZE = tuple(t / 5 for t in wx.DisplaySize())


There is a note warning about using this function in the documentation, so I suggest to follow it.

Ok, but then I think it will be a bit more complex, shell I take into consideration two monitors or is it okay if I set the size according to the first monitor? I am in the process of preparing Ubuntu on my second laptop, so now on my VirtualBox I am limited in terms of trying startup for different monitors set as default. :-( But if I get it right, [0] may represent the primary monitor anyway.

I am not sure if [0] really means primary, it is not written anywhere... if not it could be possible to determine which monitor it is according to GetPosition, but unfortunately, I do not have the second monitor to try it out.

mmm.. actually, neither on them work (neither wx.DisplaySize nor wx.Display(0).GetGeometry().Get(Size)... I need to have self.Maximize(True) to extend GRASS on the whole screen. I will have a look on it again tomorrow.

lindakarlovska · 2021-06-11T12:49:14Z

I first thought that we could employ the Data Catalog as the content pane but it is not possible since we need the Data Catalog to occupy only the small part of the window but the Best Size settings do not work for the center pane. :-( It means that the Center pane always adapts and extends according to other widgets. That would not be good:

In yesterday's video call, we decided to use the Map Display as the Content pane instead. We can either follow the first layout proposal where Map Displays are in notebooks. There is a nice functionality that the notebook can be split so that we can see several Map Displays side by side as I suggested in the mock-up...:

Will we be able to collapse several map displays as tabs too as the tabs in the display pane in the mock-up? (I lack the right vocabulary, sorry)

Well, we can have several Map Displays as tabs in the notebook:

but! :-) we can also split the notebook in order to see MapDisplays side by side (the previous picture).
But as the notebook is the Content pane, we can pull out neither the whole notebook nor one of the "side by side" Map Displays on the second monitor.

Have I answered your question Vero? :-) I am not sure if I get it right.

veroandreo · 2021-06-11T14:17:04Z

Well, we can have several Map Displays as tabs in the notebook:

but! :-) we can also split the notebook in order to see MapDisplays side by side (the previous picture).
But as the notebook is the Content pane, we can pull out neither the whole notebook nor one of the "side by side" Map Displays on the second monitor.

Have I answered your question Vero? :-) I am not sure if I get it right.

Yes! That's exactly what I meant. IMHO, It looks beautiful! :-)
I understand the "limitation" though of not being able of pulling the the maps to a second monitor

petrasovaa · 2021-06-11T14:29:54Z

gui/wxpython/main_window/frame.py

@@ -87,7 +92,7 @@ def __init__(
        id=wx.ID_ANY,
        title=None,
        workspace=None,
-        size=globalvar.GM_WINDOW_SIZE,
+        size=wx.Display(0).GetGeometry().GetSize(),


This should be wx.Display().GetGeometry() which gives you the wx.Rect of the display the application was started on.

But wx.DisplaySize() gives me (3520, 1080) when I have 2 displays.

Also you shouldn't need this here since you Maximize the window later, no?

Ok. I already get it. :-) We do not have to deal with different sizes of 2 displays at all.

lindakarlovska · 2021-06-13T14:06:21Z

@petrasovaa it works for me, could we merge it? If some problem occurs we can deal with that later. This PR is just the initial simple sketch.

* develop: wxGUI/Single-Window GUI: arrangement of basic widgets (OSGeo#1621)

basic widgets arrangement and removing methods containing notebook st…

d3003e8

…uff, widget sizes hardcoded

lindakarlovska marked this pull request as draft June 5, 2021 18:26

lindakarlovska added GUI wxGUI related gsoc Reserved for Google Summer of Code student(s) labels Jun 5, 2021

petrasovaa reviewed Jun 6, 2021

View reviewed changes

lindakarlovska closed this Jun 9, 2021

lindakarlovska reopened this Jun 9, 2021

wenzeslaus added this to In progress in Single Window Layout GUI via automation Jun 9, 2021

lindakladivova added 2 commits June 10, 2021 01:18

MapDisplay made as the content pane (only blank for testing), no hard…

4894f8d

…coded sizes

black

bd8860c

lindakladivova added 2 commits June 10, 2021 02:38

notebook stuff is no longer needed

f408620

min size not needed

7e1d046

lindakarlovska marked this pull request as ready for review June 10, 2021 09:23

petrasovaa reviewed Jun 11, 2021

View reviewed changes

function wx.DisplaySize not used

44d4eeb

petrasovaa reviewed Jun 11, 2021

View reviewed changes

getting of display size corrected

76a7e4b

petrasovaa merged commit 69b2fe5 into OSGeo:master Jun 13, 2021

Single Window Layout GUI automation moved this from In progress to Done Jun 13, 2021

a0x8o added a commit to a0x8o/grass that referenced this pull request Jun 14, 2021

wxGUI/Single-Window GUI: arrangement of basic widgets (OSGeo#1621)

5871ca8

a0x8o added a commit to a0x8o/grass that referenced this pull request Jun 15, 2021

Merge branch 'develop'

9ef7aa9

* develop: wxGUI/Single-Window GUI: arrangement of basic widgets (OSGeo#1621)

neteler added this to the 8.0.0 milestone Dec 9, 2021

ninsbl pushed a commit to ninsbl/grass that referenced this pull request Oct 26, 2022

wxGUI/Single-Window GUI: arrangement of basic widgets (OSGeo#1621)

d0038f4

ninsbl pushed a commit to ninsbl/grass that referenced this pull request Feb 17, 2023

wxGUI/Single-Window GUI: arrangement of basic widgets (OSGeo#1621)

d2079e3

a0x8o added a commit to a0x8o/grass that referenced this pull request May 9, 2024

wxGUI/Single-Window GUI: arrangement of basic widgets (OSGeo#1621)

603790c

a0x8o added a commit to a0x8o/grass that referenced this pull request May 21, 2024

wxGUI/Single-Window GUI: arrangement of basic widgets (OSGeo#1621)

a9f2ebb

a0x8o added a commit to a0x8o/grass that referenced this pull request Jun 3, 2024

wxGUI/Single-Window GUI: arrangement of basic widgets (OSGeo#1621)

ed96561

a0x8o added a commit to a0x8o/grass that referenced this pull request Jun 17, 2024

wxGUI/Single-Window GUI: arrangement of basic widgets (OSGeo#1621)

3a5870f

a0x8o added a commit to a0x8o/grass that referenced this pull request Jun 17, 2024

wxGUI/Single-Window GUI: arrangement of basic widgets (OSGeo#1621)

5bdb150

a0x8o added a commit to a0x8o/grass that referenced this pull request Jun 27, 2024

wxGUI/Single-Window GUI: arrangement of basic widgets (OSGeo#1621)

e41f1e8

a0x8o added a commit to a0x8o/grass that referenced this pull request Jul 2, 2024

wxGUI/Single-Window GUI: arrangement of basic widgets (OSGeo#1621)

257d3aa

a0x8o added a commit to a0x8o/grass that referenced this pull request Jul 10, 2024

wxGUI/Single-Window GUI: arrangement of basic widgets (OSGeo#1621)

17eee70

a0x8o added a commit to a0x8o/grass that referenced this pull request Jul 23, 2024

wxGUI/Single-Window GUI: arrangement of basic widgets (OSGeo#1621)

fedf78b

a0x8o added a commit to a0x8o/grass that referenced this pull request Jul 23, 2024

wxGUI/Single-Window GUI: arrangement of basic widgets (OSGeo#1621)

486c039

a0x8o added a commit to a0x8o/grass that referenced this pull request Jul 31, 2024

wxGUI/Single-Window GUI: arrangement of basic widgets (OSGeo#1621)

df44da0

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

wxGUI: Single-Window GUI: arrangement of basic widgets #1621

wxGUI: Single-Window GUI: arrangement of basic widgets #1621

lindakarlovska commented Jun 5, 2021

petrasovaa Jun 6, 2021

petrasovaa commented Jun 6, 2021

veroandreo commented Jun 7, 2021

lindakarlovska commented Jun 8, 2021 •

edited

Loading

veroandreo commented Jun 8, 2021

mlennert commented Jun 8, 2021 via email

lindakarlovska commented Jun 9, 2021

lindakarlovska commented Jun 10, 2021 •

edited

Loading

veroandreo commented Jun 10, 2021

petrasovaa Jun 11, 2021

lindakarlovska Jun 11, 2021

lindakarlovska Jun 11, 2021

lindakarlovska Jun 11, 2021

lindakarlovska commented Jun 11, 2021

veroandreo commented Jun 11, 2021

petrasovaa Jun 11, 2021

petrasovaa Jun 11, 2021

lindakarlovska Jun 12, 2021 •

edited

Loading

lindakarlovska commented Jun 13, 2021

wxGUI: Single-Window GUI: arrangement of basic widgets #1621

wxGUI: Single-Window GUI: arrangement of basic widgets #1621

Conversation

lindakarlovska commented Jun 5, 2021

petrasovaa Jun 6, 2021

Choose a reason for hiding this comment

petrasovaa commented Jun 6, 2021

veroandreo commented Jun 7, 2021

lindakarlovska commented Jun 8, 2021 • edited Loading

veroandreo commented Jun 8, 2021

mlennert commented Jun 8, 2021 via email

lindakarlovska commented Jun 9, 2021

lindakarlovska commented Jun 10, 2021 • edited Loading

veroandreo commented Jun 10, 2021

petrasovaa Jun 11, 2021

Choose a reason for hiding this comment

lindakarlovska Jun 11, 2021

Choose a reason for hiding this comment

lindakarlovska Jun 11, 2021

Choose a reason for hiding this comment

lindakarlovska Jun 11, 2021

Choose a reason for hiding this comment

lindakarlovska commented Jun 11, 2021

veroandreo commented Jun 11, 2021

petrasovaa Jun 11, 2021

Choose a reason for hiding this comment

petrasovaa Jun 11, 2021

Choose a reason for hiding this comment

lindakarlovska Jun 12, 2021 • edited Loading

Choose a reason for hiding this comment

lindakarlovska commented Jun 13, 2021

lindakarlovska commented Jun 8, 2021 •

edited

Loading

lindakarlovska commented Jun 10, 2021 •

edited

Loading

lindakarlovska Jun 12, 2021 •

edited

Loading