Re: Review: FULLSCREEN_MONITORS Hint

[Grant Patterson <grantp vmware com>]

My apologies for not responding to this sooner; it drifted down my inbox and I 
forget there were unanswered emails.

I like this idea. It seems to cover all the cases we've discussed so far. Here's 
a diff for the spec. (It also incorporates Lubos's latest snip.) What do people 
think?


    <sect2>
		<title>_NET_WM_FULLSCREEN_MONITORS</title>
		<programlisting><![CDATA[
_NET_WM_FULLSCREEN_MONITORS, CARDINAL[]/32
]]></programlisting>
      <para>
A read-only list of 4 monitor indices indicating the top, bottom, left, and
right edges of the window when fullscreened. The indices are from
the set returned by the Xinerama extension.
      </para>
      <para>
An empty list indicates that the Window Manager will obey normal fullscreen
conventions, as if the property did not exist.
      </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 or the monitor containing the
non-full-screen window.
      </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.l[0] = the monitor whose top edge defines the top edge of the 
fullscreened window
  data.l[1] = the monitor whose bottom edge defines the bottom edge of the 
fullscreened window
  data.l[2] = the monitor whose left edge defines the left edge of the 
fullscreened window
  data.l[3] = the monitor whose right edge defines the right edge of the 
fullscreened window
  data.l[4] = source indication
  other data.l[] 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>
      <para>
In the event of a change in monitor configuration, the application is
responsible for re-computing the monitors on which it wants to appear.
The window manager may continue using the same monitor indices as before
or simply clear the list, returning to "normal" fullscreen.
      </para>
   	</sect2>


Dana Jansens wrote:
> On 2/13/08, Mark Tiefenbruck <mark fluxbox org> wrote:
> > Here's one more suggestion for a format. There seems to be some
> >  difficulty about what the bounds for the window should actually be.
> >  Should the window fully contain all monitors listed or be fully
> >  contained by all monitors listed? Or something different? I don't
> >  think any of the suggestions have really addressed this. Perhaps the
> >  most versatile approach (without giving complete control to the
> >  application) is to specify four monitors, one for each edge. Then, for
> >  example, the top edge of the window would be aligned with the top edge
> >  of the corresponding monitor, and the same logic would apply to the
> >  other three edges.
>
> I think that this models what is actually trying to be requested
> better than the previous four suggestions.  I think it may be worth
> defining what would be expected when a specified monitor disappears or
> resizes though.  This option also requires some more complcated code
> in any app that lets you change this hint, as it needs to pick
> different monitors based on how they fit together, but with the
> advantage of letting apps really specify what they mean.
>
> The monitor indices approach is problematic as there are many monitor
> configuration requests whose correct behaviours are completely
> undefined, such as choosing 1 and 2 from below:
> -------------
> | 1 | 3 | 2 |
> -------------
>
> The upper limit on the number of monitors is also troubling.
>
>
> dana
--- ../wm-spec-old.xml	2007-10-19 13:52:44.773627000 -0700
+++ wm-spec-1.4.xml	2008-03-03 18:38:53.026919000 -0800
@@ -1629,6 +1629,68 @@
 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 4 monitor indices indicating the top, bottom, left, and
+right edges of the window when fullscreened. The indices are from
+the set returned by the Xinerama extension.
+      </para>
+      <para>
+An empty list indicates that the Window Manager will obey normal fullscreen
+conventions, as if the property did not exist.
+      </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 or the monitor containing the
+non-full-screen window.
+      </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.l[0] = the monitor whose top edge defines the top edge of the fullscreened window
+  data.l[1] = the monitor whose bottom edge defines the bottom edge of the fullscreened window
+  data.l[2] = the monitor whose left edge defines the left edge of the fullscreened window
+  data.l[3] = the monitor whose right edge defines the right edge of the fullscreened window
+  data.l[4] = source indication
+  other data.l[] 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>
+      <para>
+In the event of a change in monitor configuration, the application is
+responsible for re-computing the monitors on which it wants to appear.
+The window manager may continue using the same monitor indices as before
+or simply clear the list, returning to "normal" fullscreen.
+      </para>
+   	</sect2>
 </sect1>