[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Infrastructural complexity.
From: |
Thomas Lord |
Subject: |
Re: Infrastructural complexity. |
Date: |
Sat, 18 Jul 2009 21:01:35 -0700 |
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
- Re: Infrastructural complexity., (continued)
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/19
- Re: Infrastructural complexity., Thomas Lord, 2009/07/19
- RE: Infrastructural complexity., Drew Adams, 2009/07/19
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/19
- Re: Infrastructural complexity., Richard Stallman, 2009/07/19
- Re: Infrastructural complexity., Thomas Lord, 2009/07/18
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/18
- Re: Infrastructural complexity.,
Thomas Lord <=
- 16 (Re: Infrastructural complexity.), Thomas Lord, 2009/07/20
- Re: 16 (Re: Infrastructural complexity.), Thomas Lord, 2009/07/20
- Re: 16 (Re: Infrastructural complexity.), Thomas Lord, 2009/07/20
- Re: 16 (Re: Infrastructural complexity.), Lennart Borgman, 2009/07/20
- Re: 16 (Re: Infrastructural complexity.), Thomas Lord, 2009/07/20
- Re: 16 (Re: Infrastructural complexity.), Lennart Borgman, 2009/07/20
- Re: 16 (Re: Infrastructural complexity.), Thomas Lord, 2009/07/20
- Re: Infrastructural complexity., martin rudalics, 2009/07/19
- Re: Infrastructural complexity., joakim, 2009/07/19
- Re: Infrastructural complexity., Miles Bader, 2009/07/19