Re: Infrastructural complexity.

[Thomas Lord]

On Fri, 2009-07-17 at 02:30 +0200, Lennart Borgman wrote:
> On Fri, Jul 17, 2009 at 1:44 AM, Thomas Lord<address@hidden> wrote:
> > On Fri, 2009-07-17 at 00:54 +0200, Lennart Borgman wrote:

> >> I am unable to understand the "four framelettes". Why not just let any
> >> window be a framelette if desired?

> > I can't imagine a clean way for that to work
> > for two reasons.   First, it would allow unbounded
> > nesting of framelettes.

> Why is that a problem?

That's a good question.  

I'm concerned because I'm imagining the case of
user commands that operate on the "selected-frame".
(I'm also concerned about how it looks to lisp
programs but it's easiest to introduce the concerns
from a user perspective.)

C-x 1 is a suitable example.  As thing stands,
C-x 1 operates on *the* selected frame.  With
the "four framelettes" notion, now there is a little
potential ambiguity but we can (usefully, I think) say
that if the current window is in a framelette, the
command applies to that framelette - otherwise to the frame.
It's easy for users to learn that the framelettes around
the borders are one context for C-x 1, the space in the
middle a separate context.


Now, what if the current window is underneath a hierarchical
list of 5 framelettes?  I, the user, want C-x 1 to apply
to the third framelette in that list.   What then?
I can't think of any usable solution.  How is a user supposed
to figure out, trivially, without stopping and solving a 
slightly complicated puzzle, which window to select to 
achieve that desired C-x 1 effect?

I think that as window configuration support improves
and as things get more IDEish, "C-x 1" will be the least
of our problems.   That is, I anticipate a wealth of 
fancier ways for users to manipulate window config but,
with arbitrarily nested frames, the question still hangs
of how a user is supposed to select which, in a nested 
list, window config to change.

It's for reasons like that I think a simple, 2-level
frame/framelette abstraction is a good idea.

As I wrote the above another idea occurred to me:
What about (as in, e.g., GIMP) "tear offs".  A tear
off is a separate window-system window (not an emacs
window) and could be naturally modeled as a 
framelette in a 2-layer frame/framelette hierarchy.

Putting on my "dabble in mysticism" hat, there
are essentially three natural numbers greater than
0:  one, two, and "many".  Nesting of frame-like
things is currently at "one".  How about trying "two"
before jumping to "many".  Sometimes "two" is enough.



> > Second, I don't know about
> > you but I can't think of any semantics for window
> > configurations that would make that work nicely.

> I am not sure I understand. I just think of it as you described it (on
> a general level).

I don't see the "generalization" you are after.




> - Inside a framelett window commands just affects that framelet.
> - A framelet inside a framelet is just treated as any other window if
> you are outside of it.
> - A framelet or a single window can be marked as "protected", but that
> holds just when you are doing operations from windows inside the same
> level. (Inside they do not touch them by definitions above and outside
> they are just seen as windows on the same level which may be protected
> or not.) 

I don't see any convincing story about how user's have a 
friendly nice model for those "levels" beyond two.

I also don't see any useful way to treat framelettes
other than the four around the periphery (perhaps
plus "tear offs").  




> > That being said, I'll observe that "any window a
> > framelette" is easily construed as a generalization
> > of "four fixed framelettes in the customary toolbar
> > and panel positions" and so it is not so absurd to think
> > of starting with the conceptually simpler "four framelettes"
> > idea and generalizing later if clear answers appear
> > for unbounded nesting and window configuration semantics.
> 
> I do not understand why you think this is conceptually easier to
> restrict it to four framelettes and just one sublevel. Why is it
> easier? (I guess the code would have to handle that restriction and it
> just seems more complicated to me.)

Another way to say why it is easier is that users don't
have to think very hard about "frame v. framelette".  They
can just learn, as they have with so many other GUIs, that there
are these four special areas around the main content of a window-system
window (and perhaps "tear offs").


-t