Re: Review: FULLSCREEN_MONITORS Hint
- From: "Dana Jansens" <danakj orodu net>
- To: "Grant Patterson" <grantp vmware com>, wm-spec-list gnome org
- Subject: Re: Review: FULLSCREEN_MONITORS Hint
- Date: Mon, 3 Mar 2008 21:59:22 -0500
On 3/3/08, Grant Patterson <grantp vmware com> wrote:
> 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
Other hints with a fixed list size would describe this as:
_NET_WM_FULLSCREEN_MONITORS, CARDINAL[4]/32
Maybe this should do the same for consistency.
> ]]></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
"when the fullscreen state is enabled" or something might be better
here. Fullscreened isn't really an adjective.
> 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.
Why do you specify this behavior, as opposed to just having the
property removed from the window entirely?
> </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
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?
> ]]></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>
I like this overall :)
- dana
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]