Re: Infrastructural complexity.

[martin rudalics]

> 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