Re: Improving work areas with multiple monitors

[Alberts Muktupāvels <alberts muktupavels gmail com>]

Hi,

I have created merge request for this:

https://gitlab.freedesktop.org/xdg/xdg-specs/merge_requests/22

Any objections?

On Mon, Dec 31, 2018 at 1:48 PM Alberts Muktupāvels <alberts muktupavels gmail com> wrote:

On Mon, Dec 31, 2018 at 10:44 AM Martin Flöser <mgraesslin kde org> wrote:

Am 2018-12-27 22:22, schrieb Alberts Muktupāvels via wm-spec-list:
> Hi,
>
> I would like to improve work area situation with multiple monitors.
> Before writing patches I would like to hear what you think about my
> idea.
>
> 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.

This property probably make sense only with new workarea... For example if we have left and right monitors put side by side. How do you set strut for panel / dock that is placed on right monitors left edge? And more importantly - how would look generated work area? It has to ignore strut or one monitor is excluded from work area.

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
> _NET_WORKAREAS_D0, _NET_WORKAREAS_D1 and _NET_WORKAREAS_D2 properties.
>
> 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?

Per desktop? Because existing  _NET_WORKAREA property have work areas for each desktop? If you have one desktop you have one rectangle with work area, if you have 5 desktops it will contain 5 rectangles. To speak truth I don't know if you really can have different work areas for different desktops and/or if anyone support/use that...  I don't want to introduce more changes then needed.

x, y, width, height is work area rectangle. Property format basically is same as _NET_WORKAREA, except multiple rectangles are not for desktops, but for monitors. For example two 1280x1024 side by side monitors with 24px panel on right monitor left edge would produce following property - _NET_WORKAREAS_D0, [0, 0, 1280, 1024], [1304, 0, 1256, 1024]. And if you have more then one desktop there would be _NET_WORKAREAS_D1, _NET_WORKAREAS_D2... properties. That way you can read property for current desktop - _NET_WORKAREAS_D{_NET_CURRENT_DESKTOP}.

Did I make it more understandable or still not clear enough?

>
> Window managers adding support for this would need to add
> _NET_WORKAREAS hint to _NET_SUPPORTED.

And also for the new strut property.

Right. I mention only work area hint because I have not seen that panels / docks would check if property is supported. They just set both properties and window managers first tries to read _NET_WM_STRUT_PARTIAL and then _NET_WM_STRUT.

 

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

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.

I guess it is fine, but it should not be reason to not update/improve spec, right?

For example, how do you workaround following bug?:

https://bugreports.qt.io/browse/QTBUG-60513

Anyway, I am not after workarounds... Right now it does not look like big and complicated changes so I don't see why would this be rejected unless someone sees big problems that I have not thought about.

For example metacity based window managers already have work areas for each monitor - all it needs is to make it available to clients / toolkits. It would be enough to allow toolkits to fix mentioned bug. And adding _NET_WM_STRUT_AREA would make it possible to correctly calculate work areas for many configurations.

I plan to write patches for metacity, mutter, gtk and maybe also for compiz.

--

Alberts Muktupāvels

--

Alberts Muktupāvels