From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: Infrastructural complexity. Date: Sat, 18 Jul 2009 02:05:12 +0200 Message-ID: References: <20090712180623.GA1009@muc.de> <1247784574.6302.83.camel@dell-desktop.example.com> <1247787842.6302.90.camel@dell-desktop.example.com> <1247793496.6302.112.camel@dell-desktop.example.com> <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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1247875550 18836 80.91.229.12 (18 Jul 2009 00:05:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Jul 2009 00:05:50 +0000 (UTC) Cc: Chong Yidong , Lennart Borgman , emacs-devel@gnu.org, Juri Linkov , Martin Rudalics , Stefan Monnier , Alan Mackenzie , Drew Adams To: Thomas Lord Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 18 02:05:42 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 1MRxQp-0007So-Ks for ged-emacs-devel@m.gmane.org; Sat, 18 Jul 2009 02:05:39 +0200 Original-Received: from localhost ([127.0.0.1]:50557 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MRxQo-0007ji-JI for ged-emacs-devel@m.gmane.org; Fri, 17 Jul 2009 20:05:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MRxQk-0007jT-2h for emacs-devel@gnu.org; Fri, 17 Jul 2009 20:05:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MRxQf-0007jG-2D for emacs-devel@gnu.org; Fri, 17 Jul 2009 20:05:33 -0400 Original-Received: from [199.232.76.173] (port=33026 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MRxQe-0007jD-Uu for emacs-devel@gnu.org; Fri, 17 Jul 2009 20:05:28 -0400 Original-Received: from iwfs.imcode.com ([82.115.149.64]:37135 helo=gate.verona.se) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MRxQe-0003yb-AV for emacs-devel@gnu.org; Fri, 17 Jul 2009 20:05:28 -0400 Original-Received: from localhost.localdomain (IDENT:1005@localhost [127.0.0.1]) by gate.verona.se (8.13.4/8.11.4) with ESMTP id n6I05DTr020094; Sat, 18 Jul 2009 02:05:15 +0200 In-Reply-To: <1247871746.6287.157.camel@dell-desktop.example.com> (Thomas Lord's message of "Fri, 17 Jul 2009 16:02:26 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux) 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:112650 Archived-At: Thomas Lord writes: > On Fri, 2009-07-17 at 14:46 -0400, Chong Yidong wrote: > >> I recall that we had an inconclusive discussion over the relative merits >> of two proposals, one by Joakim that (IIRC) relied on window parameters, >> and another by Martin that uses more built-in code. Does anyone have >> any new thoughts about this? > > Yes. > > One observation is that RMS posted some pretty > challenging questions about whether or not > window groups are a good design, and these have > gone unanswered: > > http://lists.gnu.org/archive/html/emacs-devel/2008-05/msg01769.html > > I think window groups are clearly not a good > design, essentially because the questions he raises > don't have good answers that I can see. But, > there's no need to dwell on the negative. > > I've been looking at Eclipse screenshots and I > regularly use programs like the OpenOffice suite > and Gimp and so forth. I think I have some "feel" > for what the goals are here. > > The "GUIs" you are going up against here tend > to have window system windows with a main edit > area. At the sides or bottom or top are various > "panels" that perform ancillary functions. Each > panel might have such things as a toolbar or set > of "tabs". The window system window as a whole will > have menus, a toolbar, and perhaps something like > a minibuffer. In addition there are floating > dialog boxes and "tear offs". So the question seems > to be how to cleanly and simply improve emacs so > that analogous things are possible. > > To me, Emacs frames are an existing abstraction that > is already very close to how each individual panel, > tearoff, and pop-up works. One key difference is > that the panels etc. are one-level-deep subordinate > to one main "frame" - sometimes graphically nested > in them and always having commands that operate on the > basis of that subordination. But they're frames. > One example is if you look at Eclipse screen shots and > the panel down the left side - sometimes it is split > vertically; sometimes the user gets to add additional > vertical splits. That panel is, to my mind, a frame -- > just with this slight "subordination" addition and > perhaps a restriction about which buffers can be displayed > there. > > When I think about what kinds of buffers would appear > in those "side frames", tear-offs etc. well, they would > tend to be "controllers" that effect the parent frame. > "Parent frame" is a new concept but the code for those > controllers would also be new code so it isn't unreasonable > to ask new code to recognize a new concept. > > There are other GUI details in the IDEs and other programs. > Tab bars, and toolbars and such. I can imagine clean > ways to add those to the extent they aren't already there > but nothing even remotely close to "window groups" seems > a reasonable abstraction -- at least unless it can be explained > much better than it already has been. > > Something like "framelettes" seems a much better design > to me. > > FWIW, of course. > -t When I did my "windowgroups" patch, I wanted to find a simple abstraction on which you could build other things. The ECB already does all the Eclips:ish things you describe above, and I just wanted to find the smalles set of primitives suitable to get rid of the advice ECB uses. In my mind most of the issues in RMS observations are answered in some way by ECB, and "windowgroups" lets ECB be included in Emacs, since advice is no longer needed. A "windowgroup" is similar to an Emacs frame, inside another emacs frame. I like this better than using several Emacs frames. > -- Joakim Verona