Re: Infrastructural complexity.

[joakim]

Thomas Lord <address@hidden> 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