Review: FULLSCREEN_MONITORS Hint

[Grant Patterson-2]

Hello,

My colleague David Trowbridge has been communicating on the wm-spec list about a
FULLSCREEN_MONITORS hint, which would allow a fullscreen window to stretch over
multiple monitors. We here on the VMware Linux UI team need such a hint to
provide a more reliable multi-monitor experience in our Linux desktop products.

The basic idea: windows can specify a list of monitor indexes. If they do, they
will be stretched over the monitors when fullscreened. Implementing this
functionality is straightforward; we have preliminary patches for Metacity,
Enlightenment, Fluxbox, and fvwm. Philip Langdale will probably implement for
Sawfish. A kwin developer has also expressed willingness to help.

See what we propose adding below, and diff attached. I'm pretty new to all this,
so comment/correct as necessary. One issue: the size of XClientMessageEvent.data
is limited to 20 bytes. It seems reasonable to me that systems will have no more
than 255 monitors, and that clients of FULLSCREEN_MONITORS will not specify more
than 18 monitors to use while in fullscreen. Let me know if this isn't safe, or
if there's a better way to reliably specify some subset of a system's monitors.

Thanks very much!


grant


     <sect2>
                <title>_NET_WM_FULLSCREEN_MONITORS</title>
                <programlisting><![CDATA[
_NET_WM_FULLSCREEN_MONITORS, CARDINAL[]/32
]]></programlisting>
       <para>
A read-only list of monitor indeces indicating which monitors the window should
stretch over when fullscreened. The window must cover the union of all
monitors indicated in the list.
       </para>
       <para>
An empty list indicates that the Window Manager should obey normal fullscreen
conventions; that is, the window should be stretched over the monitor
it was in when it entered fullscreen.
       </para>
       <para>
When placing children of the window (i.e. popup dialogs), the Window Manager
centers them on the monitor containing the mouse cursor, provided
this is a monitor listed in _NET_WM_FULLSCREEN_MONITORS. If not, children
are placed on the first monitor indicated in the list.
       </para>
       <para>
A Client wishing to change this list MUST send a _NET_WM_FULLSCREEN_MONITORS
client message to the root window. The Window Manager MUST
keep this list updated to reflect the current state of the window.
       </para>
<programlisting><![CDATA[
   window  = the respective client window
   message_type = _NET_WM_FULLSCREEN_MONITORS
   format = 32
   data.b[0] = number of monitors (n) in the list
   data.b[1] = first monitor in the list
   data.b[2] = second monitor in the list
   ...
   data.b[n+1] = source indication
   other data.b[] elements = 0
]]></programlisting>
       <para>
See <xref linkend="sourceindication"/> for details on the source indication.
       </para>
    </sect2>

--- wm-spec-old.xml 2007-10-19 13:52:44.773627000 -0700
+++ wm-spec-1.4.xml 2007-11-21 17:23:49.624827000 -0800
@@ -1629,6 +1629,47 @@
 window.
  </para>
  </sect2>
+    <sect2>
+ <title>_NET_WM_FULLSCREEN_MONITORS</title>
+ <programlisting><![CDATA[
+_NET_WM_FULLSCREEN_MONITORS, CARDINAL[]/32
+]]></programlisting>
+      <para>
+A read-only list of monitor indeces indicating which monitors the window should
+stretch over when fullscreened. The window must cover the union of all
+monitors indicated in the list.
+      </para>
+      <para>
+An empty list indicates that the Window Manager should obey normal fullscreen
+conventions; that is, the window should be stretched over the monitor
+it was in when it entered fullscreen.
+      </para>
+      <para>
+When placing children of the window (i.e. popup dialogs), the Window Manager
+centers them on the monitor containing the mouse cursor, provided
+this is a monitor listed in _NET_WM_FULLSCREEN_MONITORS. If not, children
+are placed on the first monitor indicated in the list.
+      </para>
+      <para>
+A Client wishing to change this list MUST send a _NET_WM_FULLSCREEN_MONITORS
+client message to the root window. The Window Manager MUST
+keep this list updated to reflect the current state of the window.
+      </para>
+<programlisting><![CDATA[
+  window  = the respective client window
+  message_type = _NET_WM_FULLSCREEN_MONITORS
+  format = 32
+  data.b[0] = number of monitors (n) in the list
+  data.b[1] = first monitor in the list
+  data.b[2] = second monitor in the list
+  ...
+  data.b[n+1] = source indication
+  other data.b[] elements = 0
+]]></programlisting>
+      <para>
+See <xref linkend="sourceindication"/> for details on the source indication.
+      </para>
+   </sect2>
 </sect1>
 
 

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

[Mark Tiefenbruck]

> See what we propose adding below, and diff attached. I'm pretty new to all this,
> so comment/correct as necessary. One issue: the size of XClientMessageEvent.data
> is limited to 20 bytes. It seems reasonable to me that systems will have no more
> than 255 monitors, and that clients of FULLSCREEN_MONITORS will not specify more
> than 18 monitors to use while in fullscreen. Let me know if this isn't safe, or
> if there's a better way to reliably specify some subset of a system's monitors.

Presumably the monitors used will be a rectangular array. You could
just specify a top-left and bottom-right monitor. Or maybe it would be
easier to specify x- and y-coordinates in the root window, since
monitors tend to be of different sizes. It really depends on what the
applications are, I think.

About your proposal, I think you should let each window manager decide
what to do with transient windows, though I'd expect most will do what
you suggested. Also, I don't see any reason the property should be
written by the window manager and communicated through client
messages. The client can add the hint to its own window with fewer
context switches.

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

[Havoc Pennington]

Hi,

Mark Tiefenbruck wrote:
> About your proposal, I think you should let each window manager decide
> what to do with transient windows, though I'd expect most will do what
> you suggested. Also, I don't see any reason the property should be
> written by the window manager and communicated through client
> messages. The client can add the hint to its own window with fewer
> context switches.
>

A model where the WM maintains the property (when window is mapped) and
the client has to ask to change it, allows the WM to modify the property
without races - similar to how we handle _NET_WM_STATE.

Havoc

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

[Havoc Pennington]

Hi,

Thanks for the patch! I dug out some past threads, for reference:

http://mail.gnome.org/archives/wm-spec-list/2007-March/msg00002.html
http://mail.gnome.org/archives/wm-spec-list/2007-April/msg00001.html

Grant Patterson wrote:
>       <para>
> When placing children of the window (i.e. popup dialogs), the Window
> Manager
> centers them on the monitor containing the mouse cursor, provided
> this is a monitor listed in _NET_WM_FULLSCREEN_MONITORS. If not, children
> are placed on the first monitor indicated in the list.
>       </para>

Probably this should be a suggestion not a requirement - the important
thing to have in the spec is something like "windows transient for the
window with _NET_WM_FULLSCREEN_MONITORS set, such as those with type
_NET_WM_WINDOW_TYPE_DIALOG, are generally expected to be positioned
(e.g. centered) with respect to only one of the monitors." You could
continue to say something like "An example window manager policy might
center the dialog on the fullscreen monitor containing the mouse
pointer, or just choose the first fullscreen monitor if none of them
contain the mouse pointer."

It might be useful to explain some example applications that could use
the hint.

"Virtual machine software may use this hint to have a virtual operating
system instance that will see multiple monitors. The multiple physical
monitors are mapped to multiple virtual monitors controlled by the
virtual machine software."

"This hint might also be used by a movie or presentation application
that could allow the user to set up a movie or presentation such that it
spans multiple monitors."

"In both cases, the application would have some user interface allowing
the user to configure which monitors the application fullscreens to. The
window manager need not provide such an interface, though it could."

I guess some of this could go in the "Implementation Notes" rather than
in the main part of the spec.

> <programlisting><![CDATA[
>   window  = the respective client window
>   message_type = _NET_WM_FULLSCREEN_MONITORS
>   format = 32
>   data.b[0] = number of monitors (n) in the list
>   data.b[1] = first monitor in the list
>   data.b[2] = second monitor in the list
>   ...

It might be nice to say explicitly what these indexes correspond to.
(Are they the indexes returned by the Xinerama extension?)

Another thing to address, I believe the Xinerama config can now change
dynamically... what happens then? (I'm not sure, to be honest, what the
plans are in this area from X.org)

Havoc

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

[Mark Tiefenbruck]

> > Also, I don't see any reason the property should be
> > written by the window manager and communicated through client
> > messages. The client can add the hint to its own window with fewer
> > context switches.
> >
>
> A model where the WM maintains the property (when window is mapped) and
> the client has to ask to change it, allows the WM to modify the property
> without races - similar to how we handle _NET_WM_STATE.

Part of my assumption was that the WM doesn't need to modify this
property at all. I can't think of a reason why it would, since this is
purely a request from the client for specific treatment.

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

[Lubos Lunak]

On Thursday 22 of November 2007, Grant Patterson wrote:
> Hello,
>
> My colleague David Trowbridge has been communicating on the wm-spec list
> about a FULLSCREEN_MONITORS hint, which would allow a fullscreen window to
> stretch over multiple monitors. We here on the VMware Linux UI team need
> such a hint to provide a more reliable multi-monitor experience in our
> Linux desktop products.

 Given that this can be useful also e.g. for Xine, I'd support this, with some
comments:

> The basic idea: windows can specify a list of monitor indexes. If they do,
> they will be stretched over the monitors when fullscreened. Implementing
> this functionality is straightforward; we have preliminary patches for
> Metacity, Enlightenment, Fluxbox, and fvwm. Philip Langdale will probably
> implement for Sawfish. A kwin developer has also expressed willingness to
> help.

 Do I know him :) ?

>      <sect2>
>                 <title>_NET_WM_FULLSCREEN_MONITORS</title>
>                 <programlisting><![CDATA[
> _NET_WM_FULLSCREEN_MONITORS, CARDINAL[]/32
> ]]></programlisting>
>        <para>
> A read-only list of monitor indeces indicating which monitors the window
> should stretch over when fullscreened. The window must cover the union of

 "The window should" - this is a request to the WM and there's no guarantee it
will honour it.

> all monitors indicated in the list.
>        </para>
>        <para>
> An empty list indicates that the Window Manager should obey normal
> fullscreen conventions; that is, the window should be stretched over the
> monitor it was in when it entered fullscreen.

 This part is a bit ambiguous - is it just explicitly saying that empty
property is the same like no property at all, or that the WM should remember
the state before the property was set?

>        </para>
>        <para>
> When placing children of the window (i.e. popup dialogs), the Window
> Manager centers them on the monitor containing the mouse cursor, provided
> this is a monitor listed in _NET_WM_FULLSCREEN_MONITORS. If not, children
> are placed on the first monitor indicated in the list.

 As already said by Havoc, this is imposing a policy. This should be a
recommendation at most.

>        </para>
>        <para>
> A Client wishing to change this list MUST send a
> _NET_WM_FULLSCREEN_MONITORS client message to the root window. The Window
> Manager MUST
> keep this list updated to reflect the current state of the window.
>        </para>

 I'd support Mark's opinion here - if the property is only client's, then
there's no need for a message and you won't have any arbitrary limitations.
The client can simply set the property to a list of Xinerama screens.

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http//www.suse.cz
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Havoc Pennington]

Hi,

Mark Tiefenbruck wrote:
>> A model where the WM maintains the property (when window is mapped) and
>> the client has to ask to change it, allows the WM to modify the property
>> without races - similar to how we handle _NET_WM_STATE.
>
> Part of my assumption was that the WM doesn't need to modify this
> property at all. I can't think of a reason why it would, since this is
> purely a request from the client for specific treatment.
>

The case mentioned in the original thread in April was that the WM could
offer a UI for dragging the window between monitors (as we do for
maximized windows). e.g. maybe you can Alt+drag the fullscreen window.
In that case, or if the WM or pager in any other way offers UI for
changing fullscreen monitors, we'd need the _NET_WM_STATE-style approach.

Another possibility: it might be annoying to treat 1-monitor fullscreen
as a special case; the WM might want to just set FULLSCREEN_MONITORS to
the single monitor the app is on, in that case, if the app did not set
FULLSCREEN_MONITORS itself.

If we require the WM to do that, then the app could also avoid special
cases; it could be written to simply watch and respond to
FULLSCREEN_MONITORS, thus adapting to any WM-originated or
pager-originated changes in the property.

A WM might even have a global default. For example, I could say "for any
app not specifying FULLSCREEN_MONITORS, fullscreen that app to these two
monitors." Seems pretty useful for the presentation/movie case.

The NET_WM_STATE-style setup also allows the WM to intercept and deny
FULLSCREEN_MONITORS requests. In the past, the cases where we don't have
WM "redirection" of a request have often been a problem (SetInputFocus
most notably).

It's possible the question of "what happens when the Xinerama config
changes?" matters here too, though I guess it probably doesn't - the
answer to that is probably just to document that which of the app or WM
is supposed to deal with it.

Anyway, overall I think the _NET_WM_STATE style approach is simply
cleaner and more future-safe, even if nobody has immediate plans to
support WM or pager changes to this property.

I guess it hinges on whether you consider the FULLSCREEN_MONITORS
property to be a state ("the monitors the app is fullscreened on") or a
hint about a state ("the monitors the app would like to be fullscreened
on, with current state stored separately by the WM"). I think it's more
robust if the property _is_ the state (as with _NET_WM_STATE), rather
than the app's request, since then everyone can share knowledge of what
the state is.

It just makes sense to me that a persistent property is the state, and
requests to change the state are a one-time client message. vs. using a
persistent property to mean a request to change a state, where the state
is then internal to the WM.

To sum up:
  - allows WM or pager to have UI to modify fullscreen monitor state
  - allows WM to support a global default FULLSCREEN_MONITORS
    for movies and presentations that don't set it
    (note: should patch spec to suggest not setting it to use
     the default)
  - allows app to figure out whether the WM is honoring its
    FULLSCREEN_MONITORS hint
  - conceptually, distinguishes between the state and the request to
    change state

Havoc

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

[Lubos Lunak]

On Monday 26 of November 2007, Havoc Pennington wrote:
> Mark Tiefenbruck wrote:
> >> A model where the WM maintains the property (when window is mapped) and
> >> the client has to ask to change it, allows the WM to modify the property
> >> without races - similar to how we handle _NET_WM_STATE.
> >
> > Part of my assumption was that the WM doesn't need to modify this
> > property at all. I can't think of a reason why it would, since this is
> > purely a request from the client for specific treatment.
...
> The NET_WM_STATE-style setup also allows the WM to intercept and deny
> FULLSCREEN_MONITORS requests. In the past, the cases where we don't have
> WM "redirection" of a request have often been a problem (SetInputFocus
> most notably).

 SetInputFocus is something different - it does something, it sets the focus.
Setting a property does not change a window geometry.

> I guess it hinges on whether you consider the FULLSCREEN_MONITORS
> property to be a state ("the monitors the app is fullscreened on") or a
> hint about a state ("the monitors the app would like to be fullscreened
> on, with current state stored separately by the WM"). I think it's more
> robust if the property _is_ the state (as with _NET_WM_STATE), rather
> than the app's request, since then everyone can share knowledge of what
> the state is.

 The state is what the window geometry is. And almost nobody should care about
what it actually is:
- e.g. video-playing apps could use this property to play video either on one
monitor or all (I know Xine has such option), but they don't really care what
the result is, they should just use the geometry they get from the WM (as
ICCCM says).
- for the WM there's no difference
- pagers don't care either, they simply show geometry (besides, the property
applies only if the window is fullscreened, so bye-bye simple logic)
- apps like VMWare that possibly could care already have the logic for setting
right values for the property, so getting it the other way around shouldn't
be difficult. Moreover they're supposed to try to cope with whatever geometry
they get, just like everybody else (ICCCM again)

 Therefore I support the opinion that it should be just a one-way request like
e.g. setting _NET_WM_NAME.

> To sum up:
>   - allows WM or pager to have UI to modify fullscreen monitor state

 That does not depend on it. The WM can do it regardless and pager can set the
property.

>   - allows WM to support a global default FULLSCREEN_MONITORS
>     for movies and presentations that don't set it

 Again, that does not depend on it.

>     (note: should patch spec to suggest not setting it to use
>      the default)

 Agreed here. In fact, probably part of the reason why I think it should be
just a request and not a state is that I'd like to keep it what it should
be - special case, not something everybody uses.

>   - allows app to figure out whether the WM is honoring its
>     FULLSCREEN_MONITORS hint

 If they really care that much, they can figure out from the geometry. The
fact that they shouldn't care and this being asynchronous however IMHO makes
this point void.

 VMWare people: What will happen if the WM will not honour the request?

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http//www.suse.cz
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Grant Patterson-2]

On Nov 24, 2007, at 11:48 a, Mark Tiefenbruck wrote:
>
> Presumably the monitors used will be a rectangular array. You could
> just specify a top-left and bottom-right monitor. Or maybe it would be
> easier to specify x- and y-coordinates in the root window, since
> monitors tend to be of different sizes. It really depends on what the
> applications are, I think.

Both of those are interesting ideas, in particular specifying root  
window coordinates. That would make this a bigger hint/property: an  
application could essentially place its window anywhere it wants,  
which might be more leeway than people are comfortable with. There  
could be some kind of sanity checking, but expecting the WM to  
confirm that the given coordinates actually specify a union of  
monitors would necessitate implementing a rather messy algorithm in  
each WM. What do people think about specifying x/y/width/height  
instead of a list of monitor indices?
>
> About your proposal, I think you should let each window manager decide
> what to do with transient windows, though I'd expect most will do what
> you suggested.

Sure. As Havoc suggested, I'll suggest the center-on-cursor's-monitor  
functionality, but not require it.

> Also, I don't see any reason the property should be
> written by the window manager and communicated through client
> messages. The client can add the hint to its own window with fewer
> context switches.

Lots of discussion over this issue. I'm pretty indifferent. The  
simple hint is easier to implement, and is the way I did things in  
preliminary patches for a few WMs. I see the advantages of the  
message/property setup, where the WM can refuse to cooperate, set the  
property itself, have defaults, etc. On the other hand, clients can  
indeed check for WM compliance by examining their geometry.

While I'm all for allowing WMs to reject FULLSCREEN_MONITORS  
requests, I really hope such cases are rare. The way we got here in  
the first place was WMs' reluctance to place windows over panels and  
other functionality designed to save the client window from itself.  
If FULLSCREEN_MONITORS doesn't work in reasonable circumstances,  
it'll be no better than the current hack we have to implement multi-
monitor full screen.
>
>   Mark

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

[Grant Patterson-2]

Here's an updated patch; I tried taking most suggestions into  
account. Kept it as a message/property for now, though that could  
change.

On Nov 25, 2007, at 10:57 a, Havoc Pennington wrote:
> Another thing to address, I believe the Xinerama config can now  
> change dynamically... what happens then? (I'm not sure, to be  
> honest, what the plans are in this area from X.org)

I'd say the best thing to do would be to clear the property,  
reverting to "traditional" fullscreen. The client window would be  
expected to give a new request when it learns about the Xinerama  
change. Preserving the property in any way would just make things wacky.

On the other hand, if this hint wound up being in terms of a root  
window geometry, more burden would be on the client to listen to  
Xinerama changes and respond accordingly.

On Nov 26, 2007, at 8:27 a, Lubos Lunak wrote:
> On Thursday 22 of November 2007, Grant Patterson wrote:
>> A kwin developer has also expressed willingness to
>> help.
>
>  Do I know him :) ?

I don't recall exactly, but when David told me this he might've been  
referring to you :-)
Anyway, having done several implementations already, each additional  
isn't much extra work.

>> A read-only list of monitor indeces indicating which monitors the  
>> window
>> should stretch over when fullscreened. The window must cover the  
>> union of
>
>  "The window should" - this is a request to the WM and there's no  
> guarantee it
> will honour it.

But here we're talking about the read-only property, which must be in  
sync with the window's actual geometry--not the client request.


     <sect2>
                <title>_NET_WM_FULLSCREEN_MONITORS</title>
                <programlisting><![CDATA[
_NET_WM_FULLSCREEN_MONITORS, CARDINAL[]/32
]]></programlisting>
       <para>
A read-only list of monitor indices indicating which monitors the  
window will
stretch over when fullscreened. The indices are from the set returned  
by the Xinerama extension. The window must cover the union of all  
monitors indicated in
the list.
       </para>
       <para>
An empty list indicates that the Window Manager will obey normal  
fullscreen
conventions, as if the property did not exist; that is, the window  
will be
stretched over the monitor it was in when it entered fullscreen.
       </para>
       <para>
Windows transient for the window with _NET_WM_FULLSCREEN_MONITORS  
set, such as
those with type _NEW_WM_WINDOW_TYPE_DIALOG, are generally expected to be
positioned (e.g. centered) with respect to only one of the monitors.  
This
might be the monitor containing the mouse pointer, the monitor  
containing the
non-full-screen window, or simply the first indicated in the list if  
neither
of those apply.
       </para>
       <para>
A Client wishing to change this list MUST send a  
_NET_WM_FULLSCREEN_MONITORS
client message to the root window. The Window Manager MUST
keep this list updated to reflect the current state of the window.
       </para>
<programlisting><![CDATA[
   window  = the respective client window
   message_type = _NET_WM_FULLSCREEN_MONITORS
   format = 8
   data.b[0] = number of monitors (n) in the list
   data.b[1] = index of first monitor in the list
   data.b[2] = index of second monitor in the list
   ...
   data.b[n+1] = source indication
   other data.b[] elements = 0
]]></programlisting>
       <para>
See <xref linkend="sourceindication"/> for details on the source  
indication.
       </para>
       <para>
Virtual machine software may use this hint to have a virtual  
operating system
instance that sees multiple monitors. The application window  
stretches over
several monitors, giving the appearance that these monitors have been  
taken
over by the guest virtual machine.
       </para>
       <para>
This hint might also be used by a movie or presentation application  
allowing
users to display the media spanned over several monitors.
       </para>
       <para>
In both cases, the application would have some user interface  
allowing users
to configure which monitors the application fullscreens to. The  
window manager
need not provide such an interface, though it could.
       </para>
    </sect2>



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

[Elijah Newren]

On Nov 27, 2007 3:40 PM, Grant Patterson <grantp@...> wrote:

> On Nov 24, 2007, at 11:48 a, Mark Tiefenbruck wrote:
> >
> > Presumably the monitors used will be a rectangular array. You could
> > just specify a top-left and bottom-right monitor. Or maybe it would be
> > easier to specify x- and y-coordinates in the root window, since
> > monitors tend to be of different sizes. It really depends on what the
> > applications are, I think.
>
> Both of those are interesting ideas, in particular specifying root
> window coordinates. That would make this a bigger hint/property: an
> application could essentially place its window anywhere it wants,
> which might be more leeway than people are comfortable with. There
> could be some kind of sanity checking, but expecting the WM to
> confirm that the given coordinates actually specify a union of
> monitors would necessitate implementing a rather messy algorithm in
> each WM. What do people think about specifying x/y/width/height
> instead of a list of monitor indices?

I'd rather it were just a width/height -- measured in monitors rather
than pixels -- than either of those two choices.  Does that make
sense?  Sure, WMs would have to figure out how to squeeze the window
appropriately if the window was on monitors of different sizes, but
that's no different than the original hint either.  Also, I don't see
why the x & y should be hardcoded in the message (an initial placement
hint, maybe?)  -- does it not make sense to let the user move the
virtual machine "window" to some different set of monitors with the
same overall size?


Just my $0.02,
Elijah
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[David Trowbridge]

On Nov 27, 2007 8:10 PM, Elijah Newren <newren@...> wrote:
> I'd rather it were just a width/height -- measured in monitors rather
> than pixels -- than either of those two choices.  Does that make
> sense?  Sure, WMs would have to figure out how to squeeze the window
> appropriately if the window was on monitors of different sizes, but
> that's no different than the original hint either.  Also, I don't see
> why the x & y should be hardcoded in the message (an initial placement
> hint, maybe?)  -- does it not make sense to let the user move the
> virtual machine "window" to some different set of monitors with the
> same overall size?

This is fine for the plain old xinerama way of doing things where monitors are
arranged via "LeftOf" and the like.  It doesn't cope at all with the
complexities
introduced by the new RandR hotness (which basically lets you put a monitor
anywhere on the framebuffer that you like).

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

[Nathaniel Smith]

On Wed, Nov 28, 2007 at 12:33:31AM -0800, David Trowbridge wrote:
> This is fine for the plain old xinerama way of doing things where monitors are
> arranged via "LeftOf" and the like.  It doesn't cope at all with the
> complexities
> introduced by the new RandR hotness (which basically lets you put a monitor
> anywhere on the framebuffer that you like).

I don't understand how anything anyone has talked about can deal in
a sensible way with arbitrary arrangements of monitors on the
frame-buffer -- in fact, I don't even know what basic things like
the existing _NET_FULLSCREEN would mean in this case.

Do you have a plan that handles these complexities?  Could you
elaborate on it?

-- Nathaniel

--
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Lubos Lunak]

On Wednesday 28 of November 2007, Nathaniel Smith wrote:

> On Wed, Nov 28, 2007 at 12:33:31AM -0800, David Trowbridge wrote:
> > This is fine for the plain old xinerama way of doing things where
> > monitors are arranged via "LeftOf" and the like.  It doesn't cope at all
> > with the complexities
> > introduced by the new RandR hotness (which basically lets you put a
> > monitor anywhere on the framebuffer that you like).
>
> I don't understand how anything anyone has talked about can deal in
> a sensible way with arbitrary arrangements of monitors on the
> frame-buffer -- in fact, I don't even know what basic things like
> the existing _NET_FULLSCREEN would mean in this case.
>
> Do you have a plan that handles these complexities?  Could you
> elaborate on it?

 That'a very good point. I myself don't see how one could reasonably handle
anything that doesn't look like current Xinerama setups, except by simply
ignoring the screens that don't fit. I'm pretty upset by libXinerama on
openSUSE10.3 with Intel now claiming that there are e.g. two screens
1400x1050+0+0 and 1024x768+0+0.

 Which I guess means, unless somebody has some great idea, that we can ignore
all this "RandR hotness".

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http//www.suse.cz
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Lubos Lunak]

On Wednesday 28 of November 2007, Grant Patterson wrote:

> Here's an updated patch; I tried taking most suggestions into  
> account. Kept it as a message/property for now, though that could  
> change.
>
> On Nov 25, 2007, at 10:57 a, Havoc Pennington wrote:
> > Another thing to address, I believe the Xinerama config can now  
> > change dynamically... what happens then? (I'm not sure, to be  
> > honest, what the plans are in this area from X.org)
>
> I'd say the best thing to do would be to clear the property,  
> reverting to "traditional" fullscreen. The client window would be  
> expected to give a new request when it learns about the Xinerama  
> change. Preserving the property in any way would just make things wacky.
>
> On the other hand, if this hint wound up being in terms of a root  
> window geometry, more burden would be on the client to listen to  
> Xinerama changes and respond accordingly.

 I think the best way here would be doing nothing special. That is, just like
with normal fullscreened window the WM would possibly adjust the geometry to
fit, it would do the same here. If a client for some reason would want to
alter the setup, it can do so when detecting the config change (which means
it has to live for a moment with geometry it doesn't want, but it has to
handle that anyway).

 The only problem may be that the property might be temporarily out-of-sync
with reality (e.g. non-existent monitor). Which is yet another reason why I
don't like to use the property for keeping the state.

 Also, on a related note, it might make sense to have e.g. -1 as value
meaning "all monitors", so that e.g. video players don't have to handle all
the details related to this manually.

> On Nov 26, 2007, at 8:27 a, Lubos Lunak wrote:
> > On Thursday 22 of November 2007, Grant Patterson wrote:
> >> A read-only list of monitor indeces indicating which monitors the  
> >> window
> >> should stretch over when fullscreened. The window must cover the  
> >> union of
> >
> >  "The window should" - this is a request to the WM and there's no  
> > guarantee it
> > will honour it.
>
> But here we're talking about the read-only property, which must be in  
> sync with the window's actual geometry--not the client request.

 I see. I didn't (and still don't) see any point in having another property
announcing something that's obvious to those few that might possibly care. I
don't find this property to carry any useful information.

 However, I overlooked the source indication field in the message, which makes
sense, to distinguish between pagers and apps. Therefore I now support the
message.

>        <para>
> An empty list indicates that the Window Manager will obey normal  
> fullscreen
> conventions, as if the property did not exist.

 I'd cut this paragraph here,

> ; that is, the window  
> will be
> stretched over the monitor it was in when it entered fullscreen.

 as this is unnecessary specifying of what the WM's policy should be.

>        </para>
...

 Other than that, I'm ok with the rest.
 
--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http//www.suse.cz
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Lubos Lunak]

> > On Nov 26, 2007, at 8:27 a, Lubos Lunak wrote:
> > > On Thursday 22 of November 2007, Grant Patterson wrote:
> > >> A read-only list of monitor indeces indicating which monitors the  
> > >> window
> > >> should stretch over when fullscreened. The window must cover the  
> > >> union of
> > >
> > >  "The window should" - this is a request to the WM and there's no  
> > > guarantee it
> > > will honour it.
> >
> > But here we're talking about the read-only property, which must be in  
> > sync with the window's actual geometry--not the client request.
>
>  I see. I didn't (and still don't) see any point in having another property
> announcing something that's obvious to those few that might possibly care.
> I don't find this property to carry any useful information.

 Ah, but the property is needed if the state should be set right when the
window is initially mapped :-/. Ok, I guess modelling it after _NET_WM_STATE
is the least of the evils then.

>  However, I overlooked the source indication field in the message, which
> makes sense, to distinguish between pagers and apps. Therefore I now
> support the message.

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http//www.suse.cz
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Elijah Newren]

On Nov 28, 2007 8:30 AM, Lubos Lunak <l.lunak@...> wrote:
>  That'a very good point. I myself don't see how one could reasonably handle
> anything that doesn't look like current Xinerama setups, except by simply
> ignoring the screens that don't fit. I'm pretty upset by libXinerama on
> openSUSE10.3 with Intel now claiming that there are e.g. two screens
> 1400x1050+0+0 and 1024x768+0+0.
>
>  Which I guess means, unless somebody has some great idea, that we can ignore
> all this "RandR hotness".

So, given that, what do you think about using a hint that specifies
width & height (small integers specifying monitor counts instead of
pixel counts) rather than having a strict set of monitors on which the
window must lie?  Am I missing something?
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Lubos Lunak]

On Thursday 29 of November 2007, Elijah Newren wrote:

> On Nov 28, 2007 8:30 AM, Lubos Lunak <l.lunak@...> wrote:
> >  That'a very good point. I myself don't see how one could reasonably
> > handle anything that doesn't look like current Xinerama setups, except by
> > simply ignoring the screens that don't fit. I'm pretty upset by
> > libXinerama on openSUSE10.3 with Intel now claiming that there are e.g.
> > two screens 1400x1050+0+0 and 1024x768+0+0.
> >
> >  Which I guess means, unless somebody has some great idea, that we can
> > ignore all this "RandR hotness".
>
> So, given that, what do you think about using a hint that specifies
> width & height (small integers specifying monitor counts instead of
> pixel counts) rather than having a strict set of monitors on which the
> window must lie?  Am I missing something?

 That would be fine for the case I can easily imagine (video players), but I
guess this really depends on how exactly VMWare would want to use this hint.
And how it would cope with getting something different than it hoped for.

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http//www.suse.cz
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Grant Patterson-2]

I'm just using Nvidia TwinView and am relatively new to this stuff, so I don't
have a firm grasp on what is possible without the new "RandR hotness". (Can
monitors be different sizes? Can arrangements be non-linear, e.g. square of 4 or
L shape? Can 2 monitors be skewed?)

Nevertheless, it seems like we might as well make the property something that
can handle monitors anywhere on the framebuffer. This is easy enough to do with
my new favorite method: specify a top-left and bottom-right monitor; the WM
takes the bounding box of these and sets the window accordingly

I don't understand how width/height would be enough--given some horizontal
arrangement of >2 monitors and width=2 monitors, how does the WM know where to
place the window? VMware wants to change window configurations without leaving
fullscreen (go from monitors {0, 1} to {1, 2}), so using the monitor we started
fullscreen from won't cut it. Have I explained our desired functionality enough?

Regarding dealing with not getting what we want, we'd probably try the other
configurations we wanted (there's some set of monitor configurations through
which we cycle) and give up and revert to single-monitor fullscreen if
everything fails. I really hope that doesn't happen, though; our intentions are
for good, I promise!

Lubos Lunak wrote:

> On Thursday 29 of November 2007, Elijah Newren wrote:
>> On Nov 28, 2007 8:30 AM, Lubos Lunak <l.lunak@...> wrote:
>>>  That'a very good point. I myself don't see how one could reasonably
>>> handle anything that doesn't look like current Xinerama setups, except by
>>> simply ignoring the screens that don't fit. I'm pretty upset by
>>> libXinerama on openSUSE10.3 with Intel now claiming that there are e.g.
>>> two screens 1400x1050+0+0 and 1024x768+0+0.
>>>
>>>  Which I guess means, unless somebody has some great idea, that we can
>>> ignore all this "RandR hotness".
>> So, given that, what do you think about using a hint that specifies
>> width & height (small integers specifying monitor counts instead of
>> pixel counts) rather than having a strict set of monitors on which the
>> window must lie?  Am I missing something?
>
>  That would be fine for the case I can easily imagine (video players), but I
> guess this really depends on how exactly VMWare would want to use this hint.
> And how it would cope with getting something different than it hoped for.
>

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

[Elijah Newren]

On Nov 29, 2007 6:12 PM, Grant Patterson <grantp@...> wrote:
> I'm just using Nvidia TwinView and am relatively new to this stuff, so I don't
> have a firm grasp on what is possible without the new "RandR hotness". (Can
> monitors be different sizes? Can arrangements be non-linear, e.g. square of 4 or
> L shape? Can 2 monitors be skewed?)
>
> Nevertheless, it seems like we might as well make the property something that
> can handle monitors anywhere on the framebuffer. This is easy enough to do with
> my new favorite method: specify a top-left and bottom-right monitor; the WM
> takes the bounding box of these and sets the window accordingly

Bounding box?  So if you have two monitors of different sizes next to
each other and you use them, then you expect the vmware window to not
be totally visible?

> I don't understand how width/height would be enough--given some horizontal
> arrangement of >2 monitors and width=2 monitors, how does the WM know where to
> place the window? VMware wants to change window configurations without leaving
> fullscreen (go from monitors {0, 1} to {1, 2}), so using the monitor we started
> fullscreen from won't cut it. Have I explained our desired functionality enough?

Ah, I didn't realize that you wanted to update it on the fly in order
to change position.  So, we could specify an x,y (in monitor sizes)
for the upper left of the window too.  But I think the x,y part should
just be an "initial" hint, not a maintained constraint.

I really dislike hardcoding the position (e.g. specifying upper left
and bottom right corner), since I'd like the user to be able to grab
and move the window to other monitors and specifying absolute
positions doesn't seem very compatible with that.  Maybe the grab and
move case is more relevant for movie players than vmware, but I don't
want this to be a vmware-only hint.

Just my thoughts,
Elijah
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list