Re: Infrastructural complexity.

[Lennart Borgman <lennart.borgman@gmail.com>]

On Fri, Jul 17, 2009 at 1:44 AM, Thomas Lord<lord@emf.net> 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?


> 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).

- 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.)


> 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.)