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: Mon, 20 Jul 2009 16:00:29 -0700 Message-ID: <1248130829.6404.18.camel@dell-desktop.example.com> References: <20090712180623.GA1009@muc.de> <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> <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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1248131101 28999 80.91.229.12 (20 Jul 2009 23:05:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jul 2009 23:05:01 +0000 (UTC) Cc: rms@gnu.org, cyd@stupidchicken.com, lennart.borgman@gmail.com, joakim@verona.se, emacs-devel@gnu.org, juri@jurta.org, martin rudalics , monnier@iro.umontreal.ca, acm@muc.de, drew.adams@oracle.com To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 21 01:04:53 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 1MT1ud-0003zM-2i for ged-emacs-devel@m.gmane.org; Tue, 21 Jul 2009 01:04:51 +0200 Original-Received: from localhost ([127.0.0.1]:55954 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MT1uc-0003Xg-Ih for ged-emacs-devel@m.gmane.org; Mon, 20 Jul 2009 19:04:50 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MT1qe-0007kS-Nz for emacs-devel@gnu.org; Mon, 20 Jul 2009 19:00:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MT1qX-0007gc-IC for emacs-devel@gnu.org; Mon, 20 Jul 2009 19:00:41 -0400 Original-Received: from [199.232.76.173] (port=45102 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MT1qX-0007gX-C7 for emacs-devel@gnu.org; Mon, 20 Jul 2009 19:00:37 -0400 Original-Received: from smtp151.iad.emailsrvr.com ([207.97.245.151]:39448) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MT1qT-000587-Ar; Mon, 20 Jul 2009 19:00:33 -0400 Original-Received: from relay25.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay25.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 494621B4029; Mon, 20 Jul 2009 19:00:32 -0400 (EDT) Original-Received: by relay25.relay.iad.mlsrvr.com (Authenticated sender: lord-AT-emf.net) with ESMTPSA id 709E91B4004; Mon, 20 Jul 2009 19:00:30 -0400 (EDT) In-Reply-To: <871vobkny7.fsf@catnip.gol.com> 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:112871 Archived-At: Re the "tear off" confusion: I think I probably started the confusion by bringing up tear-offs in the first place. Sorry. My only point is that the addition of a (probably or at least initially non-nesting) "parent-frame" slot to frames would give a natural model for both control panels around the side of a window and for tear offs. If a window system window was really 5 frames, configurable in the ways I diagramed.... if there were "tear off frames" from tool bars.... if Emacs had a unified model for toolbars and menus ... THEN I think it would be straightforward to have Emacs extension packages that look and feel a lot like OpenOffice Writer and Eclipse. When (if?) Emacs pixmap buffers become richer in functionality it could also compete against programs like Gimp. If (when?) Emacs had a display mode for "SVG buffers", it could compete against drawing programs, presentation manager programs, etc. It would be kinda neat, from my perspective, in that with those features - 20 years worth of GUI toolkit designers repeating the mistakes of their predecessors could be flushed away. The church of Emacs would be vindicated (as if it needs it) :-) I also think it's pretty "doable". The 1 system window == 5 frames thing just can't possibly be *that* hard. The generalization of menu bars into toolbars and hierarchical command menus isn't huge and fits in nicely among existing abstractions / facilities. Improved pixmap support (e.g., "one buffer per layer" with virtual buffers overlaying them) is a huge job but one small step at a time can get it done. And, sure, the notion of "SVG buffers" is a pipe-dream and, yeah, just kind of hard to get over the first hump to achieve something minimally useful. But a boy can dream, can't he? -t On Tue, 2009-07-21 at 07:08 +0900, Miles Bader wrote: > >> AFAIK, the problem people are trying to solve right now is a way of > >> increasing the power of emacs _automatic_ control over window layout -- > >> burdening the user with the placement and moving of these sub-windows is > >> exactly what we _don't_ want to do. > > > > In my book tearing off a window does not count as automatic control. > > Why do you keep talking about "tear-off windows"? They aren't the focus > of this discussion. > > As I said in my previous message: [[I don't know if "tear off" windows > are a goal or not, but tearing off a emacs sub-window is an explicit > user action saying "ok, I as user am now assuming control over this > sub-window."']] > > In other words, they are (1) not a required feature, and (2) represent > and explicit user _escape_ from the automatic layout. The focus of this > discussion -- AFAICT -- is the automatic layout _not_ the > optional-and-fringe-feature of tear-off-windows. While tear-off windows > may be an interesting feature, and kinda cool, they are not a > particularly important feature, and are _not_ the point of the current > conversation. It'd be fine if whatever solution is decided completely > lacks that feature. > > >> They certainly don't do it well, not if you want application-specific > >> inter-relationships between a set of different windows (which is exactly > >> what we want). > > > > What's the purpose of tiling window managers when you can't tell them > > _where_ to put your windows? > > [completely OT at this point, but: to place windows. By default, most > tiling WMs, do so automatically, unless the user or the app takes the > trouble to setup some (non-default and WM-specific) mechanism to do so.] > > > Tearing off a window and putting it into a separate frame is no synonym > > for "moving" that window into a separate frame. You have to make a new > > window and you break all overlays with a 'window property in the old > > window's buffer and all references to that window stored in running > > applications (although for the user the new window appears the same as > > before). So if you consider tearing off windows "a natural thing to do" > > you only raise false hopes. > > I dunno; I haven't looked at the implementation details. It doesn't > sound particularly hard to me, offhand, to have the Emacs code move an > internal Emacs window structure to another parent frame (preserving any > pointers/whatever, but changing the frame pointer etc) in this case, but > I'll have to demur from arguing about it, since I don't have any > detailed basis on which do so. > > Since tear-off windows are not very important though, it doesn't really > matter. An implementation which creates a new Emacs window inside a new > frame seems acceptable to me as well. Or simply not having tear-off > windows. > > -Miles >