Re: Infrastructural complexity.

[Thomas Lord <lord@emf.net>]

Ok, so - in light of Lennart's stated 
uncertainty about exactly what the framelet
proposal is I figure it's useful to collect
the results of earlier discussion and
restate the framelet proposal so we have something
at least a little more concrete to work from
in this discussion.

I can't make the framelet proposal perfectly
concrete, by far.  "Perfectly concrete" would
be patches.  One big difference between the
window group proposal and framelets is that
the window group proposal has patches, more or
less.  So, I agree with anyone who says that that
is a relative weakness of the framelet proposal.

So, the proposal.  I'll present it in a 
narrative style, mixing rationales and 
introductions of concepts with proposed technical
details:

-----------------

The popular IDE(s), word processors, image editors,
etc. all use window systems windows in a nice way.
They have a main edit area "in the middle" with 
control panels along the side.   They also have 
persistent pop-up windows like "tear off menus"
and so forth -- all of which are conceptually 
subordinate to that main edit area.   The control 
panels and pop-ups can be used as specialized click-and-point
interfaces to various commands operating on the edit area,
or as "message" windows about stuff going on in the 
main edit area.

The framelet proposal for Emacs is a proposal to 
very directly model the interface style of those apps.

Given a window system window, Emacs currently says
"there is one frame in that window."  The framelet
proposal says that, no, there are five frames in that
window, four of which are "framelets".

Draw (in your imagination or on paper) a 
largish rectangle. Call that a window system window.

In the middle, draw a smaller rectangle. Call
that smaller rectangle the "main edit area".  

Now, the main edit area rectangle has four vertexes.
At each vertex, you can extend a horizontal or vertical 
line from a side of the inner rectangle to an edge of the 
outer rectangle.  (Picture the outer rectangle as containing
a tic-tac-toe grid.)

Now, imagine that you have to erase one line from 
each vertex of the inner box of the tic-tack-toe grid
to the outer rectangle.

You'll be left with four rectangles surrounding an 
inner rectangle.  The outer four are the "control panel
areas" and the inner rectangle is the main edit
area.  There are sixteen possible choices of which 
combinations of line segment to erase.  (Draw the
picture, puzzle it out.)

Now, in Emacs terms, all five of those rectangles
are frames.  In new terms, under this proposal, 
four of them are "framelet(tes)".  The one in the
middle is the ordinary frame - call it a "parent 
frame".  The other four around the side are framelets.
Framelets have a parent and the parent of these four
is the main edit area - the parent frame.

Framelets on either side can have a width of 0.
Framelets top or bottom can have a he1ight of 0.
In those cases, the corresponding frame is hiden
and not selected by ordinary frame traversal commands.
One way to set the width or height to 0 is to set
the window configuration of the framelet to nil.

Additionally, there can be framelets which are, on 
window systems, separate windows - free floating but
still with some other main edit area frame as parent.
They hide or are killed when the parent is.  They
are used for "tear-offs" and such.

So we have new functions like:

FRAMELET-P
FRAMELET-POSITION  ; returns N, S, E, W, or FLOATING
FRAMELET-PARENT    ; nil or a parent frame

And that's about it.  Lots can be built on top of this,
of course.  Interfaces very similar to Eclipse or Open Office
can be built on this.

What further details are unclear to people?

-t