[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Infrastructural complexity.
From: |
martin rudalics |
Subject: |
Re: Infrastructural complexity. |
Date: |
Tue, 21 Jul 2009 15:26:23 +0200 |
User-agent: |
Thunderbird 2.0.0.21 (Windows/20090302) |
> Nonetheless, that was a minor and optional detail, not the focus of the
thread.
This our subthread was triggered by Tom's statement
> > The "GUIs" you are going up against here tend
> > to have window system windows with a main edit
> > area. At the sides or bottom or top are various
> > "panels" that perform ancillary functions. Each
> > panel might have such things as a toolbar or set
> > of "tabs". The window system window as a whole will
> > have menus, a toolbar, and perhaps something like
> > a minibuffer. In addition there are floating
> > dialog boxes and "tear offs". So the question seems
> > to be how to cleanly and simply improve emacs so
> > that analogous things are possible.
> [...]
> > Something like "framelettes" seems a much better design
> > to me.
Richard's request
> > It might be a subtle question. To think about it, I suggest looking
> > at by asking: What is the difference between a windowgroup and a
> > framelet? Or what are the various differences?
and Juri's remark
> > I guess the difference is in frame parameters. If framelets are
> > Emacs frames inside the main Emacs frame, then they should have
> > their own menu bars, tool bars, tab bars.
so I guess they are focus of this subthread.
> It might indeed make implementing tear-off windows -- a minor feature --
> easier, at the expensive of making the _normal_ case -- automatic layout
> -- much more difficult. Not a good tradeoff, I'd wager.
The difficulty results exclusively from your assertion that the WM is
not able to honor Emacs' requests of window placement. I can't judge
that assertion because I practically always use only one frame that
occupies the entire screen. So maybe you're right - but a WM that
doesn't honor its client's placement requests is a bad WM IMHO.
> I suppose you can consider the possibility that easy tear-off windows are
> more important than automatic window layout, but it seems remote to me.
But I must consider the possibility that an automatic layout gets broken
by tearing off a window. ECB, for example, puts considerable care into
how windows are rearranged when one gets deleted.
> Well, obviously that difficulty only applies if we can't move the window
> object ("re-purpose it") into another frame. If we _can_, well then the
> window object stays the same, so no (or at least fewer) problems.
In three steps: (1) save a frame's window configuration, (2) tear off a
window from that frame and re-purpose it into another frame, (3) restore
the window configuration saved in step (1). Gets you two windows with
the same identity. No fun here, no fun at all ...
> If there's a reason we _can't_ re-purpose the window object into a
> another frame, then the issues you raise may apply. However, I do not
> know if this is actually important or not -- in many cases, it's
> perfectly valid to say "user code has to be prepared to deal with this."
I cannot think of a case where it would be even slightly valid to say
that.
martin
- Re: Infrastructural complexity., (continued)
- Re: Infrastructural complexity., Miles Bader, 2009/07/20
- Re: Infrastructural complexity., martin rudalics, 2009/07/20
- Re: Infrastructural complexity., Chong Yidong, 2009/07/20
- Re: Infrastructural complexity., Miles Bader, 2009/07/20
- Re: Infrastructural complexity., martin rudalics, 2009/07/20
- Re: Infrastructural complexity., Miles Bader, 2009/07/20
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/20
- Re: Infrastructural complexity., Thomas Lord, 2009/07/20
- Re: Infrastructural complexity., martin rudalics, 2009/07/21
- Re: Infrastructural complexity., Miles Bader, 2009/07/21
- Re: Infrastructural complexity.,
martin rudalics <=
- Re: Infrastructural complexity., Stefan Monnier, 2009/07/21
- Re: Infrastructural complexity., Thomas Lord, 2009/07/21
- Re: Infrastructural complexity., martin rudalics, 2009/07/21
- Re: Infrastructural complexity., Stefan Monnier, 2009/07/22
- Re: Infrastructural complexity., martin rudalics, 2009/07/22
- Re: Infrastructural complexity., Stefan Monnier, 2009/07/22
- Re: Infrastructural complexity., martin rudalics, 2009/07/23
- Re: Infrastructural complexity., Stefan Monnier, 2009/07/23
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/23
- Re: Infrastructural complexity., martin rudalics, 2009/07/23