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.muktupav...@gmail.com> wrote:
> 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
>
--
Alberts Muktupāvels
_______________________________________________
wm-spec-list mailing list
wm-spec-list@gnome.org
https://mail.gnome.org/mailman/listinfo/wm-spec-list
