emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Infrastructural complexity.


From: Thomas Lord
Subject: Re: Infrastructural complexity.
Date: Fri, 17 Jul 2009 16:02:26 -0700

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










reply via email to

[Prev in Thread] Current Thread [Next in Thread]