Hi,
At first blush, this does not appear to actually be a bug in
fvwm: note that fvwm detects another version of fvwm running, so it
does to window manager detection.
----------------------------------------------------------------------
__> fvwm
[FVWM][SetupICCCM2]: <<ERROR>> another ICCCM 2.0 compliant WM is running, try
-replace
----------------------------------------------------------------------
So what is going on? This is what fvwm does:
,----[ detecting another window manager ]
| sprintf(wm_sx, "WM_S%lu", Scr.screen);
| _XA_WM_SX = XInternAtom(dpy, wm_sx, False);
| _XA_MANAGER = XInternAtom(dpy, "MANAGER", False);
| _XA_ATOM_PAIR = XInternAtom(dpy, "ATOM_PAIR", False);
| _XA_TARGETS = XInternAtom(dpy, "TARGETS", False);
| _XA_MULTIPLE = XInternAtom(dpy, "MULTIPLE", False);
| _XA_TIMESTAMP = XInternAtom(dpy, "TIMESTAMP", False);
| _XA_VERSION = XInternAtom(dpy, "VERSION", False);
| _XA_WM_COLORMAP_NOTIFY = XInternAtom(dpy, "WM_COLORMAP_NOTIFY", False);
|
| /* Check for a running ICCCM 2.0 compliant WM */
| running_wm_win = XGetSelectionOwner(dpy, _XA_WM_SX);
| if (running_wm_win != None)
| {
| DBUG(
| "SetupICCCM2",
| "another ICCCM 2.0 compliant WM is running");
| if (!replace_wm)
| {
| fvwm_msg(
| ERR, "SetupICCCM2",
| "another ICCCM 2.0 compliant WM is running,"
| " try -replace");
| exit(1);
| }
| /* We need to know when the old manager is gone.
| Thus we wait until it destroys running_wm_win. */
| attr.event_mask = StructureNotifyMask;
| XChangeWindowAttributes(
| dpy, running_wm_win, CWEventMask, &attr);
| }
`----
So, is this valid? I looked at the "Xlib Programming Manual",
which says:
,----[ 4.3 Properties and Atoms ]
|
| Certain property names are predefined in the server for commonly used
| functions. The atoms for these properties are defined in
| X11/Xatom.h. To avoid name clashes with user symbols, the #define name
| for each atom has the XA_ prefix. For definitions of these properties,
| see below. For an explanation of the functions that let you get and
| set much of the information stored in these predefined properties, see
| "Inter-Client Communication Functions".
|
| The core protocol imposes no semantics on these property names, but
| semantics are specified in other X Consortium standards, such as the
| Inter-Client Communication Conventions Manual and the X Logical Font
| Description Conventions.
`----
So, heading over there to the "Inter-Client Communication
Conventions Manual", Version 2.0, X Consortium Standard, X Version
11, Release 6, we have:
,----[ 4. Client to Window Manager Communication ]
| 4.3. Communication with the Window Manager by Means of Selections
|
| For each screen they manage, window managers will acquire ownership of
| a selection named WM_Sn, where n is the screen number, as described in
| section 1.2.6. Window managers should comply with the conventions for
| "Manager Selections" described in section 2.8. The intent is for
| clients to be able to request a variety of information or services by
| issuing conversion requests on this selection.
`----
So, fvwm id indeed doing that, and can detect anothe window
manager following this (namely, another version of itself). I know
that icewm is not doing this -- so is this a bug in these window
managers for not following the Inter-Client Communication Conventions
Manual, which is an X Consortium (and NIST) Standard?
manoj
--
Drop the vase and it will become a Ming of the past. The Adventurer
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
