GNOME.org
 

Re: Review: FULLSCREEN_MONITORS Hint

If no one has any other comments, could someone (Lubos?) get this committed to the spec? Thanks! 


grant


Grant Patterson wrote:
No more comments for a few days--here's the latest revision. If no one else has comments before, say, Friday, could we go ahead with adding this to the spec? 


    <sect2>
        <title>_NET_WM_FULLSCREEN_MONITORS</title>
        <programlisting><![CDATA[
_NET_WM_FULLSCREEN_MONITORS, CARDINAL[4]/32
]]></programlisting>
      <para>
A read-only list of 4 monitor indices indicating the top, bottom, left, and
right edges of the window when the fullscreen state is enabled. The indices
are from the set returned by the Xinerama extension.
      </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 fullscreen window data.l[1] = the monitor whose bottom edge defines the bottom edge of the fullscreen window data.l[2] = the monitor whose left edge defines the left edge of the fullscreen window data.l[3] = the monitor whose right edge defines the right edge of the fullscreen window 
  data.l[4] = source indication
]]></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>


Grant Patterson wrote:
Your hurt-shins argument convinces me, someone who's new to the OSS world and could use all the consistency he can get! I can't see anything on the horizon that would warrant leaving extra space in the message, and the worst-case scenario (we'll have to add another client message later) isn't that bad. So 32-bit all around? 

Nathaniel Smith wrote:

On Thu, Mar 06, 2008 at 07:04:32PM -0500, Dana Jansens wrote:

On 3/4/08, Nathaniel Smith <njs pobox com> wrote:

On Tue, Mar 04, 2008 at 06:55:25PM -0800, Grant Patterson wrote:
 > Dana Jansens wrote:
> >There are no other data.l[] elements, only 5. That said, the data.s[] > > elements should be more than enough and allow for more things to be > > added in the future, but I realize every other hint exclusively uses 
 > > data.l[].  Anyone else have an opinion about this?
 > >
> I like the idea of using the 16-bit elements so there's room for expansion. > While I can't see any reason for this now, there might be some flags an app > would want to set to further define window manager behavior. Changed. 


Oh, please don't, there are enough bizarre and surprising
 inconsistencies in the X world as it is.  (And this would require a
 whole new special case in at least my code.)
If you want future expandability, without using a new atom, then do it 
 properly -- mark some fields as "if this field is non-zero, then
 discard the event" and some as "if this field is non-zero, then
 pretend the field is zero anyway", all that complex cruft.
 Alternatively, just accept that the way we do future expansion is by
 adding a new, extended atom, a la _NET_WM_STRUT{,_PARTIAL}...

This change was for the client message, which cannot be expanded in
the future.  The property itself would remain CARDINAL 32bit typed.

Yes, that is one of the inconsistencies I was referring to.  (The
other is that every other message in the spec uses format=32.)


It sounds to me like you misunderstood what was being made 16bit
fields.

I don't *think* I did, and nothing you've said has made me think
otherwise?  I am using "expandability" in the general sense of "adding
new capabilities to the spec", not in the narrow sense of "adding more
bytes at the end of a property".

Ultimately either approach works, of course, and I don't expect my
having to write extra code in my event handling routine[1] to weigh
*very* heavily on others (though it does seem to be the only data
point being advanced ATM).  But someone has to speak up in the name of
taste and consistency; it's not like X has such an abundance of it to
spare.  (At the very least, if we do make it a 16-bit message
can we put a capital-letter warning in the spec pointing this out?
Implementors are just going to bark their shins on it otherwise, and
setting people up for hurt shins seems mean to me.)

[1] The code I have now can only handle client messages with format 32
because, well, that's the only sort of client message that actually
exists in the wild ATM.

-- Nathaniel


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


------------------------------------------------------------------------

--- ../wm-spec-old.xml	2007-10-19 13:52:44.773627000 -0700
+++ wm-spec-1.4.xml	2008-03-11 11:22:19.418173000 -0700
@@ -1629,6 +1629,63 @@
 window.
 		</para>
 	</sect2>
+    <sect2>
+		<title>_NET_WM_FULLSCREEN_MONITORS</title>
+		<programlisting><![CDATA[
+_NET_WM_FULLSCREEN_MONITORS, CARDINAL[4]/32
+]]></programlisting>
+      <para>
+A read-only list of 4 monitor indices indicating the top, bottom, left, and
+right edges of the window when the fullscreen state is enabled. The indices
+are from the set returned by the Xinerama extension.
+      </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 fullscreen window
+  data.l[1] = the monitor whose bottom edge defines the bottom edge of the fullscreen window
+  data.l[2] = the monitor whose left edge defines the left edge of the fullscreen window
+  data.l[3] = the monitor whose right edge defines the right edge of the fullscreen window
+  data.l[4] = source indication
+]]></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>


------------------------------------------------------------------------

_______________________________________________
wm-spec-list mailing list
wm-spec-list gnome org
http://mail.gnome.org/mailman/listinfo/wm-spec-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]