From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: Infrastructural complexity. Date: Wed, 22 Jul 2009 08:32:38 -0700 Message-ID: <1248276758.7109.6.camel@dell-desktop.example.com> References: <20090712180623.GA1009@muc.de> <1247797261.6302.137.camel@dell-desktop.example.com> <1247798678.6302.156.camel@dell-desktop.example.com> <87ocrjtafd.fsf@stupidchicken.com> <1247871746.6287.157.camel@dell-desktop.example.com> <1247966060.7410.63.camel@dell-desktop.example.com> <4A62F7AD.4000609@gmx.at> <87eiscn223.fsf@catnip.gol.com> <4A643993.5080302@gmx.at> <87ljmjl9ow.fsf@catnip.gol.com> <4A648E1D.1000007@gmx.at> <877hy3l3kj.fsf@catnip.gol.com> <4A64BF58.4030001@gmx.at> <871vobkny7.fsf@catnip.gol.com> <4A658CD2.8020504@gmx.at> <1248195970.7551.33.camel@dell-desktop.example.com> <4A66E5F2.4000306@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1248276788 13573 80.91.229.12 (22 Jul 2009 15:33:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Jul 2009 15:33:08 +0000 (UTC) Cc: rms@gnu.org, cyd@stupidchicken.com, lennart.borgman@gmail.com, joakim@verona.se, emacs-devel@gnu.org, juri@jurta.org, monnier@iro.umontreal.ca, acm@muc.de, drew.adams@oracle.com, Miles Bader To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 22 17:32:59 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MTdoP-0003SK-R4 for ged-emacs-devel@m.gmane.org; Wed, 22 Jul 2009 17:32:58 +0200 Original-Received: from localhost ([127.0.0.1]:43492 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTdoO-0007Od-Vb for ged-emacs-devel@m.gmane.org; Wed, 22 Jul 2009 11:32:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTdoH-0007Ho-OK for emacs-devel@gnu.org; Wed, 22 Jul 2009 11:32:49 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTdoC-00070c-LU for emacs-devel@gnu.org; Wed, 22 Jul 2009 11:32:49 -0400 Original-Received: from [199.232.76.173] (port=44569 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTdoC-00070F-Hi for emacs-devel@gnu.org; Wed, 22 Jul 2009 11:32:44 -0400 Original-Received: from smtp131.iad.emailsrvr.com ([207.97.245.131]:36973) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MTdoB-0006ZS-7O; Wed, 22 Jul 2009 11:32:43 -0400 Original-Received: from relay3.r3.iad.emailsrvr.com (localhost [127.0.0.1]) by relay3.r3.iad.emailsrvr.com (SMTP Server) with ESMTP id 9693D44C021; Wed, 22 Jul 2009 11:32:41 -0400 (EDT) Original-Received: by relay3.r3.iad.emailsrvr.com (Authenticated sender: lord-AT-emf.net) with ESMTPSA id C27D044C079; Wed, 22 Jul 2009 11:32:39 -0400 (EDT) In-Reply-To: <4A66E5F2.4000306@gmx.at> X-Mailer: Evolution 2.22.3.1 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:113006 Archived-At: On Wed, 2009-07-22 at 12:12 +0200, martin rudalics wrote: > > Tear-off menus and toolbar controllers are > > commonly used (and are nice to use). > > And these can be implemented independently from window groups. > > > Those tiny windows could be modeled nicely, I > > think, as framelets: frames with a non-nil parent. > > What is the parent of a frame? Not an Emacs concept, I presume. It is a concept I'm trying to persuade people to use *instead of* window groups. I think that window groups are too complicated and that they add generality of dubious, perhaps negative utility. With the change I'm proposing, frames gain a new slot - a parent slot - whose value is either nil or another frame. Elisp programs can *not* modify this slot arbitrarily. No frame with a non-nil parent slot can itself be parent to another frame (at least not initially) thus nesting is limited to one level. Frames with non-nil parent slots can be created as pop-ups that can be torn off. Additionally, each frame with a nil parent slot has four children that share its same window system window. (See my earlier message with the Subject line "16 (Re: ...)".) When a parent frame is minimized or deleted, it's child frames are also minimized or deleted. This is a cleaner way, imo, to accomplish what window groups are trying to accomplish. -t