Re: Infrastructural complexity.

[Thomas Lord]

On Thu, 2009-07-30 at 11:07 +0200, martin rudalics wrote:
> > It doesn't sum to the size of the frame, that's true.
>  > Isn't it already the case, however, that the window
>  > widths and heights don't necessarily add up to the
>  > full size of the frame?  What are you worried about?

> For example `window-full-width-p' is currently calculated as

> #define WINDOW_FULL_WIDTH_P(W) \
>    (WINDOW_TOTAL_COLS (W) == FRAME_TOTAL_COLS (WINDOW_XFRAME (W)))

> This would fail with your approach when invoked on a window in the edit
> area.  We'd probably have to redefine it by asking whether that window
> is as wide as the root window of its frame.  But such things haven't
> been investigated on a wide scale yet and we'd also have to cope with
> the somewhat paradoxical situation that the root window of a frame is no
> longer as wide as the containing frame.


Suppose that the edit area contains a
window that is the full width of the edit
area but that there are control panels to
the left and right.

Would it not DTRT to, for that window, count
the space taken by the control panels as "fringe"?
That is to say that the TOTAL_COLS of the 
edit area window would match the total width
of its (whole window system window) frame. There
would be largish "fringe".  It would so happen
that the attached frames are drawn in that fringe.



> You haven't yet sketched the details of how your approach would handle
> things like `set-frame-position' or `set-frame-size'.  IIUC you have to
> intercept these functions in some sense to handle the case where someone
> wants to move or resize an attached frame.  I also have no idea how
> functions that let a user resize attached frames with the mouse and how
> mouse tracking in general will be implemented with nested frames.
> 
> For example, if in your
> 
> _______
> |_|_|_|    template
> |_|_|_|
> |_|_|_|
> 
> I have the two attached frames named 1 and 2 as this:
> 
> _______
> |_|_|1|    template
> |_|_|2|
> |_|_|_|


That's a misunderstanding of the diagrams.
To get from the template to an actual configuration
of attached frames you must erase one line
segment of the two between each vertex of the
central square and the outer square.  You should
be left with four rectangles around the side 
surrounding the edit area in the middle.  There
are 16 ways to make those erasures.  That said,
however, your questions stand so let's go
over them:

Repositioning an attached frame should either
do nothing or signal an error.  An error is
probably preferable.

Resizing an attached frame should also cause
bordering attached frames and the edit area to
resize.  Resizing an attached frame should be
constrained to not exceed the size of the containing
frame, not make the edit area too small, and not
underflow the size of the containing frame.
(For comparison, try setting frame size to 1000x1000:
the frame size is actually set to something smaller
that fits.)

Mouse control of attached frame size:  Draw
attached frames with internal borders and 
let clicks on them generate a new event type,
e.g., FRAMELET-HORIZ-BORDER, analogous to
mode-line events.



> What happens if I "move" the imaginary border between 1 and 2 up or down
> (provided I can do that at all).  Does that also resize the edit area?

Changing the size of a control panel can change the
size of the edit area but with a constraint that it
can not make the edit area (or any control panel)
"too small".


> Also an application might want to know whether the coordinates returned
> by `mouse-position' refer to the upper-left corner of the edit area or
> the primary frame.  If they refer to the upper-left corner of the
> primary frame, we probably have to, for each primary frame, specify the
> offset of the root window of that frame (the upper-left corner of the
> edit area) in order to be able to determine in which window of the edit
> area the mouse is (provided the edit area can be split).

Again, I don't see why "fringe" doesn't already
handle this.


> OTOH how would `set-mouse-position' invoked on a primary frame interpret
> its X Y arguments?  Could this move the mouse to an attached frame?

Same answer: fringe.   The (0,0) position is the
character cell in the upper left corner of the 
text box of the upper left Emacs window of the
edit area.


> I understand that you are mostly concerned with user visible functions
> like `delete-frame' or `other-frame' DTRT without changing them.  But
> having `delete-frame' DTRT wrt whether its argument is the edit area or
> an(other) attached frame is trivial.  If you specify that a primary
> frame can't live without an edit area, it goes without saying that if
> you delete the attached frame constituting the edit area, this will
> delete the containing primary frame too.

I don't see why there should be distinct first class
frame objects in elisp for the window-system-window
and the edit area.   If it is helpful to have two
frame structures internally, for implementation,
then so be it but from elisp just the one frame
that corresponds to the edit area is enough.


> Changing the underlying functions is the hard thing.  If you eventually
> come up with a sketch of how you want to address issues like the ones I
> sketched above I might be able to tell you more.

Well, there you go.

-t