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 <[EMAIL PROTECTED]> 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
_______________________________________________
wm-spec-list mailing list
wm-spec-list@gnome.org
http://mail.gnome.org/mailman/listinfo/wm-spec-list
