[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: |
Sun, 19 Jul 2009 19:38:43 -0700 |
On Fri, 2009-07-17 at 19:49 -0400, Chong Yidong wrote:
> > To me, Emacs frames are an existing abstraction that is already very
> > close to how each individual panel, tearoff, and pop-up works... 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.
>
> The proofs of concept written by Joakim and Martin already handle this
> behavior. They don't require much of a change to the usual window
> semantics, either; the only new rule is that window operations only
> effect the windows within the current window group (e.g., C-x 1 would
> not delete the windows in other groups).
To my old, stubborn, set-in-my-ways mind yes, window
groups "handle that" but in a needless way. No "new rule"
is needed for the concept of a set of windows that are the
scope of window operations - we've already got one: a frame.
> The only thing new that the "framelets" idea brings to the table is the
> possibility of a separate set of tool-bars.
I don't think that that's a fair characterization.
Framelets accomplish the use-case goals but without
complicating the window abstraction and with only a very
minor complication added to frames.
> But I don't think it's a
> big advantage considering (i) the extra engineering that would be
> required to get these extra toolbars to work, and (ii) the fact that
> Emacs is mostly keyboard-driven anyway.
There is no reason that toolbars can't be "keyboard-driven"
so I'm not sure what you are saying.
Toolbars are nice because they are a form of "passive recollection"
interface. You have to actively remember that C-f means forward-char,
passive recollection is being able to search through a menu of
commands. For very large command sets, such as found in
word processors or IDEs, support for passive recollection
command access is a good thing.
-t
- Re: Infrastructural complexity., (continued)
- Re: Infrastructural complexity., Thomas Lord, 2009/07/16
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/16
- Re: Infrastructural complexity., Thomas Lord, 2009/07/16
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/16
- Re: Infrastructural complexity., joakim, 2009/07/17
- Re: Infrastructural complexity., Chong Yidong, 2009/07/17
- Re: Infrastructural complexity., joakim, 2009/07/17
- Re: Infrastructural complexity., Thomas Lord, 2009/07/17
- Re: Infrastructural complexity., Chong Yidong, 2009/07/17
- Re: Infrastructural complexity., joakim, 2009/07/17
- Re: Infrastructural complexity.,
Thomas Lord <=
- Re: Infrastructural complexity., Miles Bader, 2009/07/20
- Re: Infrastructural complexity., Thomas Lord, 2009/07/20
- Re: Infrastructural complexity., joakim, 2009/07/17
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/17
- Re: Infrastructural complexity., Leo, 2009/07/17
- Re: Infrastructural complexity., Juri Linkov, 2009/07/18
- Re: Infrastructural complexity., Leo, 2009/07/19
- Re: Infrastructural complexity., Miles Bader, 2009/07/19
- Re: Infrastructural complexity., Thomas Lord, 2009/07/19
- Re: Infrastructural complexity., joakim, 2009/07/18