Need to provide a way to disable _NET_WM_FULLSCREEN_MONITORS hint

re, all.

The EWMH spec does not provide a way to disable or "turn off" the _NET_WM_FULLSCREEN_MONITORS hint. In other words, whatever 4 monitor indices were last used for a fullscreen window will continue to be used ad infinitum, and the only current recourse for an app that has set this hint is to keep setting it every time it wants to fullscreen, even if it's only on a single head.

I've done a bit of testing with 2 heads and the latest Compiz, KWin, and Metacity window managers and it looks like it's possible to at least confuse these WMs into not using previous monitor indices for _NET_WM_FULLSCREEN_MONITORS by passing a -1 (0xFFFFFFFF) for the 4 monitor indices. I think what this is really doing is providing an invalid monitor index that doesn't (and can't possibly) exist in Xinerama, so it's ending up being not used by the WMs.

I'd like to propose that an addition be made to the EWMH spec that makes this the official route to asking the WM to disable the _NET_WM_FULLSCREEN_MONITORS hint for a given window. It seems to follow the spirit of both the existing _NET_WM_FULLSCREEN_MONITORS section as well as _NET_WM_DESKTOP (via using 0xFFFFFFFF as an otherwise invalid and special index).

I'd like to provide a patch to the spec to provide a way to completely turn off and disable the _NET_WM_FULLSCREEN_MONITORS after it's been set. I will provide a patch to the EWMH XML file (is wm-spec-1.4.xml the right one?), but before I do that, I wanted to check with the group on my approach. Does this approach (passing 0xFFFFFFFF as monitor indices in the XClientMessageEvent that is sent to the root window) sound good to everyone? Or would it be preferable to use a different approach?

The advantage I see to doing it this way would mean that what currently works via sending an invalid monitor index would be made the official spec standard and require only minor patches to the implementing WM's to document this as opposed to using some other mechanism which would require more intrusive rework.

Thanks in advance, all! =:)

--
-[ Jason 'vanRijn' Kasper    //  http://movingparts.net ]-
-[ KDE PIM Developer         //  http://www.kde.org  ]-
-[ bash fun -> :(){ :|:&};:  //  Numbers 6:22-26 ]-

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Giles Atkinson]

That makes sense to me, but also prompts me to make an additional point about this property:  why is not specified as a conventional window hint, as well a client message to request a change?

The only way I was able to get this to work with Metacity was to map the window, pause a little with XSync() and then follow up with the client message.  That does work fine, but means there is a race that could cause a flicker as the window is first mapped on the WM's chosen default monitor and then moved.  Specifying it in the same way as _NET_WM_STATE, as both an initial property before initial (or first post-withdrawal) mapping, and a client message to change, would fix that and seems more consistent and logical.

Giles

From: wm-spec-list-bounces@... [mailto:wm-spec-list-bounces@...] On Behalf Of Jason 'vanRijn' Kasper
Sent: 05 November 2009 22:32
To: wm-spec-list@...
Subject: Need to provide a way to disable _NET_WM_FULLSCREEN_MONITORS hint

re, all.

The EWMH spec does not provide a way to disable or "turn off" the _NET_WM_FULLSCREEN_MONITORS hint. In other words, whatever 4 monitor indices were last used for a fullscreen window will continue to be used ad infinitum, and the only current recourse for an app that has set this hint is to keep setting it every time it wants to fullscreen, even if it's only on a single head.

I've done a bit of testing with 2 heads and the latest Compiz, KWin, and Metacity window managers and it looks like it's possible to at least confuse these WMs into not using previous monitor indices for _NET_WM_FULLSCREEN_MONITORS by passing a -1 (0xFFFFFFFF) for the 4 monitor indices. I think what this is really doing is providing an invalid monitor index that doesn't (and can't possibly) exist in Xinerama, so it's ending up being not used by the WMs.

I'd like to propose that an addition be made to the EWMH spec that makes this the official route to asking the WM to disable the _NET_WM_FULLSCREEN_MONITORS hint for a given window. It seems to follow the spirit of both the existing _NET_WM_FULLSCREEN_MONITORS section as well as _NET_WM_DESKTOP (via using 0xFFFFFFFF as an otherwise invalid and special index).

I'd like to provide a patch to the spec to provide a way to completely turn off and disable the _NET_WM_FULLSCREEN_MONITORS after it's been set. I will provide a patch to the EWMH XML file (is wm-spec-1.4.xml the right one?), but before I do that, I wanted to check with the group on my approach. Does this approach (passing 0xFFFFFFFF as monitor indices in the XClientMessageEvent that is sent to the root window) sound good to everyone? Or would it be preferable to use a different approach?

The advantage I see to doing it this way would mean that what currently works via sending an invalid monitor index would be made the official spec standard and require only minor patches to the implementing WM's to document this as opposed to using some other mechanism which would require more intrusive rework.

Thanks in advance, all! =:)

--
-[ Jason 'vanRijn' Kasper    //  http://movingparts.net ]-
-[ KDE PIM Developer         //  http://www.kde.org  ]-
-[ bash fun -> :(){ :|:&};:  //  Numbers 6:22-26 ]-
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

Hey Giles,

On Fri, Nov 6, 2009 at 1:49 AM, Giles Atkinson <Giles.Atkinson@...> wrote:

That makes sense to me, but also prompts me to make an additional point about this property:  why is not specified as a conventional window hint, as well a client message to request a change?

The only way I was able to get this to work with Metacity was to map the window, pause a little with XSync() and then follow up with the client message.  That does work fine, but means there is a race that could cause a flicker as the window is first mapped on the WM's chosen default monitor and then moved.  Specifying it in the same way as _NET_WM_STATE, as both an initial property before initial (or first post-withdrawal) mapping, and a client message to change, would fix that and seems more consistent and logical.

I don't think I can answer your question. I'm guessing the design discussion that took place 2 years ago on this list (http://www.mail-archive.com/wm-spec-list@.../msg00594.html and friends) hashed this out. I know it went through a couple of revisions before this hint arrived in its current form, and I wasn't part of those initial discussions.

Hm... but as to your situation... it sounds like you're trying to create a window that initially spans multiple monitors? Did you try setting _NET_WM_FULLSCREEN_MONITORS, then _NET_WM_STATE_FULLSCREEN before showing the X window?

--
-[ Jason 'vanRijn' Kasper    //  http://movingparts.net ]-
-[ KDE PIM Developer         //  http://www.kde.org  ]-
-[ bash fun -> :(){ :|:&};:  //  Numbers 6:22-26 ]-

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Dana Jansens-2]

2009/11/6 Giles Atkinson <Giles.Atkinson@...>:
> That makes sense to me, but also prompts me to make an additional point about this property:  why is not specified as a conventional window hint, as well a client message to request a change?
>
> The only way I was able to get this to work with Metacity was to map the window, pause a little with XSync() and then follow up with the client message.  That does work fine, but means there is a race that could cause a flicker as the window is first mapped on the WM's chosen default monitor and then moved.  Specifying it in the same way as _NET_WM_STATE, as both an initial property before initial (or first post-withdrawal) mapping, and a client message to change, would fix that and seems more consistent and logical.

I agree, the functionality as only a message completely misses windows
that want to map in fullscreen mode.  I would support this change.

> From: wm-spec-list-bounces@... [mailto:wm-spec-list-bounces@...] On Behalf Of Jason 'vanRijn' Kasper
> Sent: 05 November 2009 22:32
> To: wm-spec-list@...
> Subject: Need to provide a way to disable _NET_WM_FULLSCREEN_MONITORS hint
>
> re, all.
>
> The EWMH spec does not provide a way to disable or "turn off" the _NET_WM_FULLSCREEN_MONITORS hint. In other words, whatever 4 monitor indices were last used for a fullscreen window will continue to be used ad infinitum, and the only current recourse for an app that has set this hint is to keep setting it every time it wants to fullscreen, even if it's only on a single head.
>
> I've done a bit of testing with 2 heads and the latest Compiz, KWin, and Metacity window managers and it looks like it's possible to at least confuse these WMs into not using previous monitor indices for _NET_WM_FULLSCREEN_MONITORS by passing a -1 (0xFFFFFFFF) for the 4 monitor indices. I think what this is really doing is providing an invalid monitor index that doesn't (and can't possibly) exist in Xinerama, so it's ending up being not used by the WMs.
>
> I'd like to propose that an addition be made to the EWMH spec that makes this the official route to asking the WM to disable the _NET_WM_FULLSCREEN_MONITORS hint for a given window. It seems to follow the spirit of both the existing _NET_WM_FULLSCREEN_MONITORS section as well as _NET_WM_DESKTOP (via using 0xFFFFFFFF as an otherwise invalid and special index).
>
> I'd like to provide a patch to the spec to provide a way to completely turn off and disable the _NET_WM_FULLSCREEN_MONITORS after it's been set. I will provide a patch to the EWMH XML file (is wm-spec-1.4.xml the right one?), but before I do that, I wanted to check with the group on my approach. Does this approach (passing 0xFFFFFFFF as monitor indices in the XClientMessageEvent that is sent to the root window) sound good to everyone? Or would it be preferable to use a different approach?

I believe that it's the same but technically the file you'd want to
edit is here: http://webcvs.freedesktop.org/icccm-extensions/wm-spec/

> The advantage I see to doing it this way would mean that what currently works via sending an invalid monitor index would be made the official spec standard and require only minor patches to the implementing WM's to document this as opposed to using some other mechanism which would require more intrusive rework.
>
> Thanks in advance, all! =:)

This also sounds reasonable to me, as there is no "add/remove/toggle"
state indicator or anything of the type in the message now, and "all
monitors" (the usual use for 0xFFFFFFFF) can already be achieved
through using indices.


Cheers,
Dana
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list