From xemacs-m  Sat Jul 26 11:24:24 1997
Received: from komtron.com (root@gatekeeper.komtron.com [194.77.5.33])
	by xemacs.org (8.8.5/8.8.5) with SMTP id LAA17519
	for <xemacs-beta@xemacs.org>; Sat, 26 Jul 1997 11:24:19 -0500 (CDT)
Received: from slave1.komtron.com by komtron.com with SMTP id AA31997
  (5.67b/IDA-1.5 for <xemacs-beta@xemacs.org>); Sat, 26 Jul 1997 18:28:27 +0200
Received: (from Ufga@localhost) by slave1.komtron.com (8.7.5/8.7.3) with UUCP id SAA23714; Sat, 26 Jul 1997 18:29:17 +0200
X-Authentication-Warning: slave1.komtron.com: Ufga set sender to ograf@fga.de using -f
Received: by fga.de (8.8.5/8.8.5) id OAA03988
Received: by fga.de (8.8.5/8.8.5) id OAA00362
To: "William M. Perry" <wmperry@aventail.com>
Cc: xemacs-beta@xemacs.org
Subject: Re: [PATCH] XEmacs and WindowMaker...
References: <199707251530.IAA09865@kramer.in.aventail.com>
X-Face: [8r}|"6`WFUT0kiC9dBT%edO~lI5Gwog0Z@Cl=Inx|2F=+DjY#0nGtclM)9lU
        c/8JJ%b&&^:&pWh&nYlQbGSk=WdL^%f!<6a:?n)V_snw7Zc+AW10az=||e8Kv
        1PV49Qe64*68G2`)M8O$mlLQ\!O}$d8]T\L?i@$;=WA~0B[k)O.^T'x?O^=EX
        %=gt6(:hG!-|%$EZGq-Dn6r%N6xqOC4voztttHxOMp!2$o+qPAcT2k&dgO~`%
        kVcW7C<3hK[g9vVpk'#B2(f"pN,jBh`
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Oliver Graf <ograf@fga.de>
Date: 26 Jul 1997 14:39:06 +0200
In-Reply-To: "William M. Perry"'s message of "Fri, 25 Jul 1997 08:30:03 -0700"
Message-Id: <m34t9iasyd.fsf@indie.fga-intern.de>
Lines: 22
X-Mailer: Gnus v5.4.63/XEmacs 20.3(beta14) - "Vienna"

"William M. Perry" <wmperry@aventail.com> writes:

> Here's a patch that makes XEmacs play nicely with WindowMaker's session
> management.  This does not conditionalize it on HAVE_WINDOWMAKER like the
> old patch that was posted. I don't pretend to understand all the
> ramifications of not setting WM_COMMAND on an actual XEmacs frame instead
> of the small unmapped window that is used here.  But we don't need to move
> it around when frames get deleted, which is a good thing I'd imagine.

I've submitted a WM patch with full customization to Steven.

The WM_COMMAND property *should* only be set for the leader window. The leader 
window in this case is invisible (see the last hunk) because mappedWhenManaged
is set to false. This window is the leader for all other windows, has the
correct class and instance props set and keeps the WM_COMMAND so that WM knows 
how to start it.

The WM_CLIENT_LEADER stuff is set automagically by Xt as soon as the leader
window is XtRealized.

Regards,
  Oliver.

