Multi-monitor window management #5390

nfeske · 2024-11-29T12:31:19Z

With version 24.10, Sculpt OS became usable for mirrored and panoramic multi-monitor setups. In a panoramic setup, each display shows a portion of a larger panorama maintained by the nitpicker GUI server. So the displays combined behave like a very large display. The administrative user interface is already multi-monitor-aware. It is presented only on the display that hosts the mouse pointer, thereby ensuring that the entirety of the user interface is reachable at all times, and to limit the maximum size of the user interface to the resolution of the largest display (not the total panorama size, which can be much larger).

However, as the window manager/layouter/decorator are not yet multi-monitor-aware, window operations effect the entire panorama as a whole, which has several usability drawbacks:

When placing a window at far right at the panorama, and then disconnecting the display showing this part of the panorama, the window position becomes out of reach for the user. The user can fix this situation only be manually adjusting the layouter's rules file, which is not user friendly.
When maximizing a window, the windows covers the whole panorama, not only one display. In situations where the user designates displays to distinct purposes (e.g., using one display for browsing documentation while using another display for the development environment), the maximize feature interferes.
In a similar way, the current notion of virtual desktops maps poorly to the use of the entire panorama. To accommodate distinct roles of different displays well, it would be much more useful to have an independent set of virtual desktops on each display.

To overcome these drawbacks, the window layouter must be extended with the new notion of display, with the configurable mapping of screens to the present displays, and with an interactive way for arranging windows across displays and virtual desktops.

This patch enhances the window layouter with the notion of displays and the assignment of screens to displays. Issue genodelabs#5390

To accommodate multi-monitor window management, the window-layouter rules must be extended. By renaming the rules file to a version number reflecting the date of change (24.12), we prevent the loss of window-layout state when switching back and forth between different versions of the window-layouter. The default rules contain now the definition of three displays ("primary", "secondary", and "ternary") and map 3 screens to each display. Issue genodelabs#5390

This patch changes the window-layout format to support the rectangular clipping of windows at screen boundaries. The new <boundary> node defines the clipping boundary for the windows listed within the node. Boundaries are expected to be disjoint. In the example below, the "vbox" window is placed partially outside the screen area of "screen_2". <window_layout> <boundary name="screen_1" xpos="0" ypos="0" width="640" height="480"> <window id="1" title="launchpad" xpos="10" ypos="140" width="400" height="> </boundary> <boundary name="screen_2" xpos="640" ypos="0" width="800" height="600"> <window id="2" title="vbox" xpos="520" ypos="52" width="800" height="600"> <window id="3" title="terminal" xpos="650" ypos="72" width="500" height="400"> </boundary> </window_layout> The layouter uses boundaries to restrict the visiblilty of windows to their respective target areas. Until now, Sculpt relied on the fact that the window-layout ROM had the same structure as the resize-request ROM. With the addition of the <boundary> nodes, this is no longer the case. Therefore, the Sculpt manager generates a dedicated resize-request ROM now. Issue genodelabs#5390

This patch allows the user to drag windows from one target area (i.e., display) to another whereas the resizing of windows is restricted to the window's original target area. The latter point is important to ensure that the window's resize handles remain reachable at all times. Issue genodelabs#5390

This patch enables the user to interactively change the assignment of windows to screens. For screens visible side by side in a multi-monitor setup, one can now move a window from one screen to another by dragging the window title. When using screens as virtual desktops on one display, a window can be moved to another screen by switching the screen (by pressing a key matching a desired screen) while the window is dragged with the mouse. So the user can drag the window between virtual desktops. Issue genodelabs#5390

nfeske · 2024-11-29T12:48:11Z

The commit series above implements this idea for the most part.

Replace the use of pointers and the copying of XML nodes by the 'with_' pattern. Use plain struct where appropriate, replace constructors by { } initialization. Use C++20 function template syntax. Replace accessors by public constants where possible. Follow 'from_xml' convention. Follow usual 'Action' interface naming. Issue genodelabs#5390

This patch restricts the focus switching via the keyboard (Super-Tab) to windows located at visible screens. Should the currently focused window become invible, switch the focus to the most recently focused visible window. Issue genodelabs#5390

nfeske · 2024-12-03T17:08:16Z

Commit nfeske@9b2908c complements this line of work with improved focus switching via the keyboard.

The switching within the focus history (Super-Tab) is now restricted to windows that are located at visible screens. This avoids the need to tab through invisible windows, which is a nuisance when using windows scattered across several virtual desktops.

Furthermore, the focus is now automatically changed to the most recently focused visible window whenever the currently focused window becomes invisible. This happens when switching between virtual desktops. This behavior hopefully also fits well with focus handling of temporary windows. When a temporary window appears, it needs to be focused manually (to prevent focus stealing). But once the temporary window disappears, the focus returns to the previously focused window.

This patch enhances the window layouter with the notion of displays and the assignment of screens to displays. Issue genodelabs#5390

To accommodate multi-monitor window management, the window-layouter rules must be extended. By renaming the rules file to a version number reflecting the date of change (24.12), we prevent the loss of window-layout state when switching back and forth between different versions of the window-layouter. The default rules contain now the definition of three displays ("primary", "secondary", and "ternary") and map 3 screens to each display. Issue genodelabs#5390

This patch changes the window-layout format to support the rectangular clipping of windows at screen boundaries. The new <boundary> node defines the clipping boundary for the windows listed within the node. Boundaries are expected to be disjoint. In the example below, the "vbox" window is placed partially outside the screen area of "screen_2". <window_layout> <boundary name="screen_1" xpos="0" ypos="0" width="640" height="480"> <window id="1" title="launchpad" xpos="10" ypos="140" width="400" height="> </boundary> <boundary name="screen_2" xpos="640" ypos="0" width="800" height="600"> <window id="2" title="vbox" xpos="520" ypos="52" width="800" height="600"> <window id="3" title="terminal" xpos="650" ypos="72" width="500" height="400"> </boundary> </window_layout> The layouter uses boundaries to restrict the visiblilty of windows to their respective target areas. Until now, Sculpt relied on the fact that the window-layout ROM had the same structure as the resize-request ROM. With the addition of the <boundary> nodes, this is no longer the case. Therefore, the Sculpt manager generates a dedicated resize-request ROM now. Issue genodelabs#5390

This patch allows the user to drag windows from one target area (i.e., display) to another whereas the resizing of windows is restricted to the window's original target area. The latter point is important to ensure that the window's resize handles remain reachable at all times. Issue genodelabs#5390

This patch enables the user to interactively change the assignment of windows to screens. For screens visible side by side in a multi-monitor setup, one can now move a window from one screen to another by dragging the window title. When using screens as virtual desktops on one display, a window can be moved to another screen by switching the screen (by pressing a key matching a desired screen) while the window is dragged with the mouse. So the user can drag the window between virtual desktops. Issue genodelabs#5390

Replace the use of pointers and the copying of XML nodes by the 'with_' pattern. Use plain struct where appropriate, replace constructors by { } initialization. Use C++20 function template syntax. Replace accessors by public constants where possible. Follow 'from_xml' convention. Follow usual 'Action' interface naming. Issue genodelabs#5390

This patch restricts the focus switching via the keyboard (Super-Tab) to windows located at visible screens. Should the currently focused window become invible, switch the focus to the most recently focused visible window. Issue genodelabs#5390

Nitpicker used to notify GUI clients about an updated GUI info only when the total panorama size changed. However, in situations where two capture clients are swapped, the total size may stay the same whereas the relation of displays to different parts of the panorama is no longer the same. Such changes are interesting to some clients like the window layouter, which needs to update the assignement of screens to displays. This patch changes nitpicker so that each panorama change is reflected to GUI clients as a mode-info update. Issue genodelabs#5390

This allows the window layouter to ensure that input entered after switching to an empty screen won't be routed to the old focused but no longer visible window. Issue genodelabs#5390