From xemacs-m  Wed Feb  5 14:39:08 1997
Received: from crystal.WonderWorks.COM (crystal.WonderWorks.com [192.203.206.1])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id OAA04500
	for <xemacs-beta@xemacs.org>; Wed, 5 Feb 1997 14:39:06 -0600 (CST)
Received: by crystal.WonderWorks.COM 
	id QQcbpy22073; Wed, 5 Feb 1997 15:39:05 -0500 (EST)
Date: Wed, 5 Feb 1997 15:39:05 -0500 (EST)
Message-Id: <QQcbpy22073.199702052039@crystal.WonderWorks.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Kyle Jones <kyle_jones@wonderworks.com>
To: XEmacs Beta mailing list <xemacs-beta@xemacs.org>
Subject: Re: XEmacs 20.0-b93 & 20.0 dump core w/ Mule...
In-Reply-To: <rv6807qbx2.fsf@sdnp5.ucsd.edu>
References: <Pine.LNX.3.95.970205182214.303A-100000@icemark.thenet.ch>
	<QQcbpq20356.199702051830@crystal.WonderWorks.COM>
	<rv6807qbx2.fsf@sdnp5.ucsd.edu>

David Moore writes:
 > 	The problem might be in the logic of x_delete_frame which tries
 > not to delete the information of a child when the parent has already
 > been deleted.  And the code in device_delete_internal loops over frames
 > in various stages hoping to avoid ordering problems.  But I don't think
 > it's doing it right.  And I really don't think it's doing it right if
 > you have minibufferless frames and popups.  Hmm, the balloon-help and
 > floating-toolbar frames are minibuffer less.  Do they have popup
 > children?

The balloon-help frame has a minibuffer; floating-toolbar does
not.  A consequnece of the latter is that you can't delete the
parent frame of the floating toolbar frame because the parent
contains its "surrogate" minibuffer.  To avoid this I'm going to
have to make the code create an extra unmapped junk frame and
make that frame the parent of the toolbar frame.

The balloon-help frame can be a popup child of the floating
toolbar frame if the mouse is over a floating toolbar button the
first time the balloon frame appears.

