Re: patch



I've been looking at this, but it's difficult as I can't build the html / ps versions as I don't have docbook 4. If anyone knows the easiest way to upgrade a Redhat 6.2 system to make this work Id' like to know.

It seems like the changes (in the patch) are non-controversial, and are essential bugs fixes, so I'd like to see them go in :) additionally:

_NET_SUPPORTED -
seems to need clarification, like


> _NET_SUPPORTED
> _NET_SUPPORTED, ATOM[]/32
> This property MUST be set by the Window Manager to indicate which parts of
> the standard are supported. The list MUST contain all Atoms used by the
> Window Manager. This assumes that backwards incompatible changes will not be
> made to the hints (without being renamed).

<extra>
For example: considering _NET_WM_STATE both this atom and all supported states e.g. _NET_WM_STATE_MODAL, _NET_WM_STATE_STICKY, would be listed.
</extra>


_NET_WM_MOVERESIZE
don't know enough about this to comment.

Dominic's Vogt's issues. This related to inconsistent use of MUST and SHOULD. I tried to think about this, but my head just hurt :( It seems clear to me what MUST, SHOULD, etc, mean in the context of a comms protocol, but less clear in terms of a spec (partly) concerned with user interaction. I came to the conclusion that as it stands people can implement the spec, have successful interoperability, and keep users happy, though this is all yet to be proved. One interesting (but still academic IMHO) point is about _NET_WM_WINDOW_TYPE MUST be set by the client before mapping. This makes 99% of existing apps (e.g. xterm) non-complying with the spec. My view on this is that I don't care - they don't comply, but I still expect the window to get mapped, and as a sensible type.

Mattias Clasen's comments about UTF-8 may be worth considering, but I don't know much about this.

In conclusion I think we still need to add a clarification for _NET_WM_STATE, and then get the revised spec back out there as it contains important fixes.

whaddayathink ?

jools


At 02:31 12/03/2001, Havoc Pennington wrote:

Hi,

Getting off my butt here, I'm starting by applying the appended patch.

I think there are some other changes from David Wheeler and Dominik
Vogt that sound good. David your email client word-wrapped your patch,
so I didn't simply apply it, I did make many of the changes in there
but could have missed some. Dominik had a lot of suggestions that seem
good to me but I'm not sure everyone was in agreement. Comments?

Havoc


Index: wm-spec.sgml
===================================================================
RCS file: /home/freedesktop/wm-spec/wm-spec.sgml,v
retrieving revision 1.9
diff -u -u -r1.9 wm-spec.sgml
--- wm-spec.sgml        2000/11/22 21:40:56     1.9
+++ wm-spec.sgml        2001/03/11 20:21:53
@@ -1,22 +1,36 @@
-<!doctype article PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [
+<!doctype article PUBLIC "-//OASIS//DTD DocBook V4.0//EN" [
 ]>
 <article id="index">
-<artheader>
+<articleinfo>
+   <authorgroup>
+      <corpauthor>
+      <ulink url="http://www.freedesktop.org";>X Desktop Group</ulink>
+      </corpauthor>
+      </authorgroup>
 <title>Extended Window Manager Hints</title>
-<date>5 November 2000</date>
-</artheader>
+<date>10 March 2001</date>
+</articleinfo>
 <sect1>
        <title>Introduction</title>
        <sect2>
                <title>Version</title>
                <para>
-This spec is version 1.0.
+This is version 1.1 of the Extended Window Manager Hints (EWMH) spec,
+updated 10 March 2001.
                </para>
        </sect2>
        <sect2>
                <title>What is this spec?</title>
                <para>
-This spec defines interactions between window managers, applications and the utilities that form part of a desktop environment. It builds on the ICCCM [2], which defines wm/client interactions at a lower level. It was born out of a need to replace the original Gnome WM specification, although this specification has been designed to be independent of any one desktop environment.
+This spec defines interactions between window managers, applications,
+and the utilities that form part of a desktop environment.  It builds
+on the ICCCM [2], which defines WM (window manager) interactions at a
+lower level. The ICCCM does not provide ways to implement many
+features that modern desktop users expect. The GNOME and KDE desktop
+projects originally developed their own extensions to the ICCCM to
+support these features; this spec replaces those custom extensions
+with a standardized set of ICCCM additions that any desktop
+environment can adopt.
                </para>
        </sect2>
        <sect2>
@@ -82,7 +96,7 @@
 </sect2>
 <sect2>
 <title>Modality</title>
-<para>The Window Manager_TRANSIENT_FOR hint of the ICCCM allows clients to specify that a +<para>The Window Manager _TRANSIENT_FOR hint of the ICCCM allows clients to specify that a toplevel window may be closed before the client finishes. A typical example of a transient window is a dialog. Some dialogs can be open for a long time, while the user continues to work in the main window. Other dialogs have to be
@@ -183,7 +197,7 @@
 </sect2>
 <sect2>
 <title>Animated iconification</title>
-<para>Some Window Managers display some form of animation when (de-)iconfying a window. +<para>Some Window Managers display some form of animation when (de-)iconifying a window.
 This may be a line drawing connecting the corners of the window with
 the corners of the icon or the window may be opaquely moved and resized
 on some trajectory joining the window location and the icon location.</para>
@@ -286,7 +300,7 @@
The Window Manager is free to honor or reject this request. If request is honored _NET_NUMBER_OF_DESKTOPS MUST be set to the new number of desktops, _NET_VIRTUAL_ROOTS MUST be set to store the new number of desktop virtual root window IDs and _NET_DESKTOP_VIEWPORT and _NET_WORKAREA must also be changed accordingly. The _NET_DESKTOP_NAMES property MAY remain unchanged.
        </para>
        <para>
-If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out of the new range of of available desktops, then this MUST must be set to the last available desktop from the new set. If number of desktops is shrinking then clients that are still present on desktops, that are out of the new range, MUST be moved to the very last desktop from the new set. For these _NET_WM_DESKTOP MUST be updated. +If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out of the new range of available desktops, then this MUST be set to the last available desktop from the new set. If number of desktops is shrinking then clients that are still present on desktops, that are out of the new range, MUST be moved to the very last desktop from the new set. For these _NET_WM_DESKTOP MUST be updated.
        </para>
        </sect2>
        <sect2>
@@ -577,7 +591,7 @@
 _NET_WM_WINDOW_TYPE, ATOM[]/32
 ]]></programlisting>
        <para>
-This MUST be set by the Client before mapping, to a list of atoms indicating
+This SHOULD be set by the Client before mapping, to a list of atoms indicating the functional type of the window. This property SHOULD be used by the window
 manager in determining the decoration, stacking position and other behaviour
of the window. The Client SHOULD specify window types in order of preference
@@ -757,7 +771,7 @@
                </para>
                <para>
 This is an array of 32bit packed CARDINAL ARGB with high byte being A, low
-byte being B.  First two bytes are width, height.  Data is in rows, left to
+byte being B. First two cardinals are width, height. Data is in rows, left to
 right and top to bottom.
                </para>
        </sect2>
@@ -1062,10 +1076,10 @@
                </para></listitem>
        </itemizedlist>
        <para>
-[1] ICCCM Version 2.0, §4.1.2.3 and §4.1.5
+[1] ICCCM Version 2.0, &sect;4.1.2.3 and &sect;4.1.5
        </para>
        <para>
-[2] ICCCM Version 2.0, §4.2.3
+[2] ICCCM Version 2.0, &sect;4.2.3
        </para>
        </sect2>
        <sect2>

_______________________________________________
wm-spec-list mailing list
wm-spec-list gnome org
http://mail.gnome.org/mailman/listinfo/wm-spec-list





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]