Attachment:
wm-spec-1.4.xml.diff
Description: Binary data
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 itwill 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 bepositioned (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>