Re: Improving work areas with multiple monitors

Am 2018-12-27 22:22, schrieb Alberts Muktupāvels via wm-spec-list:

I would like to improve work area situation with multiple monitors.
Before writing patches I would like to hear what you think about my

First I think there should be new property for struts because existing
properties can not be used to set struts on edges between two
monitors. New property could be named _NET_WM_STRUT_AREA and used to
define rectangular area (x, y, width and height) that should be
excluded from work area. This property will need to follow at least
two rules:
- at least one edge of area must match with monitor edge. The window
manager must ignore strut if it is not placed at monitor edge.
- if strut appears on edge between two monitors it should be ignored
when calculating _NET_WORKAREA to ensure backward compatibility.

sounds fine to me.

As a note: in KWin we allow panels on shared edges to set a strut with the existing protocol. We just decided that a strut is not allowed to cover a complete screen. Technically it's a violation of the current protocol, but might be a better idea than introducing yet another property.

It could be a simple textual addition like: "Struts covering a monitor completely are ignored for that monitor"

Next and more important part is new property to allow set work areas
for multiple monitors. Currently I am thinking it could be
_NET_WORKAREAS_Dn where n is desktop number. For example if
_NET_NUMBER_OF_DESKTOPS is set to 3 then there must be

Property would have one or multiple work areas:
_NET_WORKAREAS_Dn, x, y, width, height CARDINAL[][4]/32

This property I do not understand. What is the area of x, y, width, height? Why per desktop?

Window managers adding support for this would need to add

And also for the new strut property.

Does anyone see reasons why this would not work and/or have better

As a note: KWin is feature frozen for X11. This means we will not add support for this. I don't know whether other window managers are still interested in extending the protocol. For me it's a thing which has been broken for ages and we found a workaround for the problem. I don't see a need to fix the "legacy" protocol.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]