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