Re: Review: FULLSCREEN_MONITORS Hint
- From: Grant Patterson <grantp vmware com>
- To: Grant Patterson <grantp vmware com>
- Cc: wm-spec-list gnome org, Havoc Pennington <hp redhat com>, Lubos Lunak <l lunak suse cz>, Christian Hammond <christian vmware com>
- Subject: Re: Review: FULLSCREEN_MONITORS Hint
- Date: Wed, 13 Feb 2008 13:44:22 -0800
Can we get some motion on this? We'd really like to use the spec hint in our
upcoming version of Workstation, 6.5.
See below for all the ideas I can think of for specifying what the window wants.
Attached again, and below the quote, is the patch for the spec with my favorite
method. Thanks very much!
Grant Patterson wrote:
Hi Folks,
I'd like to restart this discussion. We at VMware had some discussions and have
several ideas for how to specify what the window should cover. Pros and cons are
my own; you may have more.
1. List all the indices in the data element of the X client message, as in the
last spec patch I sent out. If we do byte-sized formatting, that's a maximum of
18 monitors that can be listed. Seems like enough to me, but maybe I'm not
forward-thinking enough. Slightly less elegant would be to make the data element
a bitfield, where each bit corresponds to a monitor that should be included or not.
Pros: We can specify any set of monitors the app can dream up; works with RandR;
easy for the app to specify; easy for WMs to implement.
2. The window specifies x, y, width, height in the root window and the WM
complies as much as it wants to. It could just do it (rather dangerous), or
round the geometry to the nearest monitor boundary, or just ignore if the
geometry isn't along monitor boundaries.
Pros: Window can just ask for what it wants. Allows for all crazy monitor
configurations
Cons: Harder for WM to implement, or we introduce a hint that lets a window do
whatever it wants--glorified override-redirect.
3. Specify top-left and bottom-right monitors and a flag to indicate whether the
window should also stretch over any monitors overlapped by the bounding box
created from the lop-left/bottom-right.
Pros: Simple to specify.
Cons: Doesn't cover all crazy monitor configurations; I don't like flags; harder
for WM to implement
4. Make FULLSCREEN_MONITORS just stretch the window over _all_ monitors and use
shaped windows to get what the window wants.
Pros: Easy on the WM side; Window does the work of setting its shape properly
(and that code already exists?).
Cons: Window could cover whatever it wants; Window has to shape itself, which is
annoying code to write for each app.
Preferences? I'm still leaning towards 1--it makes it easy to put a window on
any combination of monitors, but not give it any arbitrary shape. It's pretty
easy for both the app and the WM to implement.
grant
Havoc Pennington wrote:
Hi,
I don't think the pager could set the FULLSCREEN_MONITORS property
directly. There can be only one client (app or WM) able to modify a
property at a time, IMO. If we want pagers to be able to change this, we
should use the client message, or it's just asking for race conditions
and even infinite loops.
Look at the _NET_WM_NAME example as you mention. _NET_WM_NAME is defined
as what the _app_ requested, so any non-app client changing it is just
wrong. In fact, we have a property _NET_WM_VISIBLE_NAME for exactly this
reason, because we distinguish the state (_NET_WM_VISIBLE_NAME) from the
app's request (_NET_WM_NAME). We had to add VISIBLE_NAME because people
end up wanting to know not only what was requested, but what the WM did.
Geometry is not a full substitute because it's a separate state from
FULLSCREEN_MONITORS, much as STATE_FULLSCREEN itself (or maximized or
minimized) are separate states from geometry (even though they affect
geometry).
An example of why it's a separate state is that a FULLSCREEN_MONITORS
state exists even when the window is not in fact fullscreen. If for
example I had a FULLSCREEN_MONITORS UI in the pager, it would be
legitimate to allow setting the FULLSCREEN_MONITORS for a movie app,
even when that app was not in fullscreen mode at the time. And to have a
UI I need to know the current state.
In theory, a WM could also use a
not-exactly-the-same-size-as-the-monitor geometry for a fullscreen app.
For example I think it would be legitimate to have some kind of border
or toolbar even in fullscreen mode, if a WM really felt like it, or
legitimate to honor the size increment (grid) hints of something like a
terminal app even in fullscreen mode.
As you say the app (or pager) should always adapt to the geometry it
gets, but that is for geometry-related matters. For any app or pager UI
that displayed or allowed you to edit FULLSCREEN_MONITORS, it would be
wrong to use the geometry; instead, the FULLSCREEN_MONITORS values
should be used, since that state will exist even when the geometry does
not match it, due to e.g. not being in fullscreen state, or just some
strange WM policy.
The request+state-property approach is a superset of a just-a-property
approach that allows several additional things to work right, if those
things ever come up. That makes it more future-safe. It seems to have
little downside to do things in a more future-safe way.
If we don't do request+state-property, then down the line we might end
up adding the equivalent of _NET_WM_VISIBLE_NAME, something like
_NET_WM_ACTUAL_FULLSCREEN_MONITORS.
Havoc
_______________________________________________
wm-spec-list mailing list
wm-spec-list gnome org
http://mail.gnome.org/mailman/listinfo/wm-spec-list
_______________________________________________
wm-spec-list mailing list
wm-spec-list gnome org
http://mail.gnome.org/mailman/listinfo/wm-spec-list
<sect2>
<title>_NET_WM_FULLSCREEN_MONITORS</title>
<programlisting><![CDATA[
_NET_WM_FULLSCREEN_MONITORS, CARDINAL[]/8
]]></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, n <= 18
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>
</sect1>
--- wm-spec-old.xml 2007-10-19 13:52:44.773627000 -0700
+++ wm-spec-1.4.xml 2007-11-27 15:34:52.691662000 -0800
@@ -1629,6 +1629,64 @@
window.
</para>
</sect2>
+ <sect2>
+ <title>_NET_WM_FULLSCREEN_MONITORS</title>
+ <programlisting><![CDATA[
+_NET_WM_FULLSCREEN_MONITORS, CARDINAL[]/8
+]]></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, n <= 18
+ 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>
</sect1>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]