On Mon, Dec 31, 2018 at 10:44 AM Martin Flöser <mgraess...@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
_______________________________________________
wm-spec-list mailing list
wm-spec-list@gnome.org
https://mail.gnome.org/mailman/listinfo/wm-spec-list
