[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: Infrastructural complexity.
From: |
klaus.berndl |
Subject: |
AW: Infrastructural complexity. |
Date: |
Fri, 24 Jul 2009 16:55:14 +0200 |
Without following the complete discussion i chip in now because ECB is
mentioned and window-groups...
IMHO currently there is a "missing link" (well, probably not the right wording
but currently i have nothing better in my mind) between a window and ist
containing frame, namely the mentioned window-groups: a frame contains at least
one window-group and a window-group contains at least one window.
Especially for applications like ECB this would be a great help because such
IDEs devide the frame in several window groups (e.g. with ECB: one group
contains the special browsing windows, one the editing-windows, one the
compile-output-window) which in turn can contain arbitrary windows.
With such a window-group concept several things should/could be possible:
- preventing a group from being be deleted by C-x 1 (AFAIK currently
there is something going on to achieve this with a new window-flag,
IIRC implemented by Joakim for the next release 24.X?!)
- hiding (ie. deleting) a window-group (ie. all it's windows but no others
from outside the group)
- saving the window-configuration of exactly one group and restoring only this
window-group (if a frame allocates needed space)
- rewriting display-buffer so only a certain window-group can be
used for displaying a buffer - or the other direction: a window-group can
be prevented from being used by display-buffer for buffer display
- etc...
IMHO such a general window-group concept between the frame- and the window-
concept would alleviate writing a tool like ECB (and would make a lot of its
advices obsolete or at least much simpler)
This is the point of view of the author and maintainer of ECB ;-)
Maybe it's offtopic for the original thread (i have not followed it), so feel
free to ignore it for this discussion or reopen a new discussion...
Regards
Klaus
-----Ursprüngliche Nachricht-----
Von: address@hidden [mailto:address@hidden Im Auftrag von Lennart Borgman
Gesendet: Freitag, 24. Juli 2009 16:21
An: martin rudalics
Cc: Thomas Lord; address@hidden; address@hidden; address@hidden;
address@hidden; address@hidden; address@hidden; address@hidden; address@hidden;
Miles Bader
Betreff: Re: Infrastructural complexity.
On Fri, Jul 24, 2009 at 2:10 PM, martin rudalics<address@hidden> wrote:
>> As an example consider ECBs windows. There is currently a command in
>> ECB to hide/show them today. That could be implemented by
>> hiding/showing a window group.
>
> ECB does this by saving a window configuration, deleting the
> respective windows, and resurrecting the saved configuration when the
> user wants the windows to show up again. Resurrection occurs
> procedurally, that is by recursively splitting the root window of a frame.
Yes, maybe that is the best way, I am not sure.
> There's no problem doing that the way sketched above. I'm skeptical
> about hiding windows by giving them zero height or width, though.
I did not mean giving the zero height ot width. That would be confusing. I
meant visibility as a new property.
> My code can split any root window (or any group root window) and clone
> any saved window group into any of the two emanating halves. And it
> does not need to split windows to accomplish that.
That sounds very good. To throw away that part of my code in winsav.el I would
need three more things:
- Rotate
- Transpose
and
> The
> additional frame resizing code when a window group that spans an
> entire side of that frame is removed would have to be written but that
> seems fairly straightforward.
- Resizing.
Actually the reszing code when putting back a window tree in winsav was one of
the most frustrating pieces of code I have written because it had to fight what
the C code was doing. I think the resizing code is one of those pieces that
should be written in C. It should be much more simple there (the logic I mean
...).
- Re: Infrastructural complexity., (continued)
- Re: Infrastructural complexity., Thomas Lord, 2009/07/23
- Re: Infrastructural complexity., martin rudalics, 2009/07/24
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/24
- Re: Infrastructural complexity., martin rudalics, 2009/07/24
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/24
- Re: Infrastructural complexity., martin rudalics, 2009/07/24
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/24
- Re: Infrastructural complexity., martin rudalics, 2009/07/24
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/24
- Re: Infrastructural complexity., martin rudalics, 2009/07/25
- AW: Infrastructural complexity.,
klaus.berndl <=
- Re: AW: Infrastructural complexity., martin rudalics, 2009/07/24
- Re: AW: Infrastructural complexity., Thomas Lord, 2009/07/24
- AW: AW: Infrastructural complexity., klaus.berndl, 2009/07/25
- Re: AW: AW: Infrastructural complexity., Miles Bader, 2009/07/25
- Re: AW: AW: Infrastructural complexity., Thomas Lord, 2009/07/25
- Re: Infrastructural complexity., martin rudalics, 2009/07/24
- Re: Infrastructural complexity., Thomas Lord, 2009/07/24
- Re: Infrastructural complexity., martin rudalics, 2009/07/25
- Re: Infrastructural complexity., Stefan Monnier, 2009/07/25
- Re: Infrastructural complexity., martin rudalics, 2009/07/25