From xemacs-m  Sun Jul 27 07:43:17 1997
Received: from newman.aventail.com (root@newman.aventail.com [199.238.236.1])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id HAA29783
	for <xemacs-beta@xemacs.org>; Sun, 27 Jul 1997 07:43:16 -0500 (CDT)
Received: from kramer.in.aventail.com (wmperry@kramer.in.aventail.com [192.168.1.12])
	by newman.aventail.com (8.8.5/8.8.5) with ESMTP id FAA15190;
	Sun, 27 Jul 1997 05:43:10 -0700 (PDT)
Received: (from wmperry@localhost)
	by kramer.in.aventail.com (8.8.5/8.8.5) id FAA09236;
	Sun, 27 Jul 1997 05:42:40 -0700
To: Oliver Graf <ograf@fga.de>
Cc: "William M. Perry" <wmperry@aventail.com>, xemacs-beta@xemacs.org
Subject: Re: [PATCH] XEmacs and WindowMaker...
References: <199707251530.IAA09865@kramer.in.aventail.com> <m34t9iasyd.fsf@indie.fga-intern.de>
Errors-to: wmperry@aventail.com
Reply-to: wmperry@aventail.com
X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
 [WJopW_J.WY;
From: wmperry@aventail.com (William M. Perry)
Date: 27 Jul 1997 05:42:40 -0700
In-Reply-To: Oliver Graf's message of "26 Jul 1997 14:39:06 +0200"
Message-ID: <86sox0hdj3.fsf@kramer.in.aventail.com>
Lines: 28
X-Mailer: Gnus v5.4.59/Emacs 19.34

Oliver Graf <ograf@fga.de> writes:

> "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.

  I'm not sure why you need to (or even should) conditionalize this
particular changed based upon whether someone using it might possibly one
day maybe run windowmaker.  It seems like the right way to do things, all
the time, no matter what window manager you are running.

> 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.

  That's what I thought, which is why I didn't think it should be #ifdef
HAVE_WINDOWMAKER...

-Bill P.

