Re: Infrastructural complexity.

[Thomas Lord]

Re the "tear off" confusion:

I think I probably started the confusion by
bringing up tear-offs in the first place.
Sorry.   My only point is that the addition
of a (probably or at least initially non-nesting)
"parent-frame" slot to frames would give a natural
model for both control panels around the side of a 
window and for tear offs.

If a window system window was really 5 frames,
configurable in the ways I diagramed....  if there
were "tear off frames" from tool bars....  if
Emacs had a unified model for toolbars and menus ...
THEN I think it would be straightforward to have
Emacs extension packages that look and feel a lot
like OpenOffice Writer and Eclipse.

When (if?) Emacs pixmap buffers become richer in 
functionality it could also compete against
programs like Gimp.

If (when?) Emacs had a display mode for 
"SVG buffers", it could compete against drawing
programs, presentation manager programs, etc.

It would be kinda neat, from my perspective,
in that with those features - 20 years worth
of GUI toolkit designers repeating the mistakes of
their predecessors could be flushed away. 
The church of Emacs would be vindicated (as
if it needs it) :-)

I also think it's pretty "doable".  The 1 system
window == 5 frames thing just can't possibly be
*that* hard.   The generalization of menu bars
into toolbars and hierarchical command menus
isn't huge and fits in nicely among existing 
abstractions / facilities.   Improved pixmap
support (e.g., "one buffer per layer" with virtual
buffers overlaying them) is a huge job but one
small step at a time can get it done.  And, 
sure, the notion of "SVG buffers" is a pipe-dream
and, yeah, just kind of hard to get over the first
hump to achieve something minimally useful.  But
a boy can dream, can't he?


-t



On Tue, 2009-07-21 at 07:08 +0900, Miles Bader wrote:
> >> AFAIK, the problem people are trying to solve right now is a way of
> >> increasing the power of emacs _automatic_ control over window layout --
> >> burdening the user with the placement and moving of these sub-windows is
> >> exactly what we _don't_ want to do.
> >
> > In my book tearing off a window does not count as automatic control.
> 
> Why do you keep talking about "tear-off windows"?  They aren't the focus
> of this discussion.
> 
> As I said in my previous message:  [[I don't know if "tear off" windows
> are a goal or not, but tearing off a emacs sub-window is an explicit
> user action saying "ok, I as user am now assuming control over this
> sub-window."']]
> 
> In other words, they are (1) not a required feature, and (2) represent
> and explicit user _escape_ from the automatic layout.  The focus of this
> discussion -- AFAICT -- is the automatic layout _not_ the
> optional-and-fringe-feature of tear-off-windows.  While tear-off windows
> may be an interesting feature, and kinda cool, they are not a
> particularly important feature, and are _not_ the point of the current
> conversation.  It'd be fine if whatever solution is decided completely
> lacks that feature.
> 
> >> They certainly don't do it well, not if you want application-specific
> >> inter-relationships between a set of different windows (which is exactly
> >> what we want).
> >
> > What's the purpose of tiling window managers when you can't tell them
> > _where_ to put your windows?
> 
> [completely OT at this point, but: to place windows.  By default, most
> tiling WMs, do so automatically, unless the user or the app takes the
> trouble to setup some (non-default and WM-specific) mechanism to do so.]
> 
> > Tearing off a window and putting it into a separate frame is no synonym
> > for "moving" that window into a separate frame.  You have to make a new
> > window and you break all overlays with a 'window property in the old
> > window's buffer and all references to that window stored in running
> > applications (although for the user the new window appears the same as
> > before).  So if you consider tearing off windows "a natural thing to do"
> > you only raise false hopes.
> 
> I dunno; I haven't looked at the implementation details.  It doesn't
> sound particularly hard to me, offhand, to have the Emacs code move an
> internal Emacs window structure to another parent frame (preserving any
> pointers/whatever, but changing the frame pointer etc) in this case, but
> I'll have to demur from arguing about it, since I don't have any
> detailed basis on which do so.
> 
> Since tear-off windows are not very important though, it doesn't really
> matter.  An implementation which creates a new Emacs window inside a new
> frame seems acceptable to me as well.  Or simply not having tear-off
> windows.
> 
> -Miles
>