Re: _NET_DESKTOP_GEOMETRY, _NET_WM_HANDLED_ICONS and WM_CLIENT_MACHINE question
- From: Lubos Lunak <l lunak suse cz>
- To: wm-spec-list gnome org
- Subject: Re: _NET_DESKTOP_GEOMETRY, _NET_WM_HANDLED_ICONS and WM_CLIENT_MACHINE question
- Date: Thu, 12 Sep 2002 18:15:15 +0200
On Thursday 12 September 2002 17:24, Havoc Pennington wrote:
> Hi,
>
> Lubos Lunak <l lunak suse cz> writes:
> > _NET_DESKTOP_GEOMETRY - I'm not completely sure, does this mean the size
> > of the "whole" desktop when using viewports (and when not using, equal to
> > the screen size) ? I find 'common size of all desktops' somewhat unclear.
>
> I think your interpretation is right, based on section 2.3.
>
> > _NET_WM_HANDLED_ICONS - it's an application window property. Does it mean
> > the taskbar should set it on all toplevel windows?
>
> Maybe if any window has _NET_WM_HANDLED_ICONS, then the WM is supposed
> to assume that icons are handled?
>
> Since metacity doesn't have icons (same for kwin right) I haven't had
> to figure this out ;-)
>
> > Section 7.9 says 'WM_CLIENT_MACHINE must be set to the fully-qualified
> > domain name of the client's host.' . Correct me if I'm wrong, but
> > fully-qualified domain name is 'host.domain.com' and not just 'host'.
> > However, the code snippet in the section (both variants of it) returns
> > just 'host' .
>
> I'm not sure about this.
Is the attached patch ok for these two issues (I hope sgml is the source)? It
explains _NET_DESKTOP_GEOMETRY in more detail, and changes 7.9 to mention
that WM_CLIENT_MACHINE is usually set by XSetWMProperties(), and that it's
not guaranteed to be fully-qualified hostname (which it apparently is not).
> > _NET_WM_HANDLED_ICONS - it's an application window property. Does it mean
> > the taskbar should set it on all toplevel windows?
>
> Maybe if any window has _NET_WM_HANDLED_ICONS, then the WM is supposed
> to assume that icons are handled?
>
> Since metacity doesn't have icons (same for kwin right) I haven't had
> to figure this out ;-)
KDE doesn't support _NET_WM_HANDLED_ICONS, neither KWin nor the taskbar.
Right now I actually feel like I'll simply forbid minimalization in KWin if
there won't be anything that would provide icons (unless somebody else will
implement icons for KWin, which I doubt).
I can't find any details about this in the archives. Is anybody here actually
using it? How? (It should be probably rather a selection allowing the owner
to set _NET_WM_ICON_GEOMETRY on windows).
> > There's actually one more thing I don't find very clear, the one about
> > moving toolbars ( see
> > http://mail.gnome.org/archives/wm-spec-list/2002-June/msg00017.html ),
> > but I guess I'll first have to try if I can make it to leave all toolbar
> > moving up to the WM, so that can wait.
>
> Not sure about this either - maybe see what you have to add/clarify in
> implementing it, and we'll revise the spec accordingly...
I've now noticed the archive doesn't go to the follow-up posts when clicking
the 'Thread Next' link (they start here
http://mail.gnome.org/archives/wm-spec-list/2002-July/msg00000.html ).
My basic point here is that the WM should be IMHO responsible for moving the
toolbar and painting the decorations (especially since we have the
_NET_WM_MOVERESIZE stuff and so).
But I would need first to test it a bit, so this is not in time for 1.2 . I
first need to check in reality if the app watching for ConfigureNotify events
and suggesting docking positions in the app window will work acceptably.
Also, KWin allows transparent window moving, where it grabs the server and
moves only a rectangle instead of really moving the window (less repainting
and I even personally like it better that way) - in this case, there will be
of course no ConfigureNotify events, so I need to see how many ugly hacks
this will need. Some KDE apps allow undocking even parts of their GUI, so if
I get this to work, I could use it also for this undocking (it's much better
when the WM does border snapping and so on).
--
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o. e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/
--- wm-spec.sgml.sav Thu Sep 12 17:38:30 2002
+++ wm-spec.sgml Thu Sep 12 17:49:12 2002
@@ -328,7 +328,8 @@ If the number of desktops is shrinking a
_NET_DESKTOP_GEOMETRY width, height, CARDINAL[2]/32
]]></programlisting>
<para>
-Array of two cardinals that defines the common size of all desktops.
+Array of two cardinals that defines the common size of all desktops (this is equal to the screen size if the Window Manager doesn't support large desktops,
+otherwise it's equal to the virtual size of the desktop).
This property SHOULD be set by the Window Manager.
</para>
<para>
@@ -1526,11 +1527,11 @@ attempt to kill a process.
</para>
<para>
-WM_CLIENT_MACHINE must be set to the fully-qualified domain name of the client's
-host. This would normally be retrieved using gethostname(2). When gethostname()
-is not available on the client's platform implementors may use the value of the
-nodename field of struct utsname as returned by uname(2). An example of how to
-retrieve a value for WM_CLIENT_MACHINE:
+WM_CLIENT_MACHINE is usually set by calling XSetWMProperties(). The hostname for the current host can be be retrieved using gethostname(2), when gethostname()
+is not available on the platform implementors may use the value of the
+nodename field of struct utsname as returned by uname(2). Note also that the value of WM_CLIENT_MACHINE is not guaranteed
+to be a fully fully-qualified domain name of the host. An example of how to
+retrieve the hostname:
</para>
<para>
<programlisting><![CDATA[
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]