Re: moving window handling into lisp

[Lennart Borgman <lennart.borgman@gmail.com>]

On Fri, Aug 21, 2009 at 2:40 PM, martin rudalics<rudalics@gmx.at> wrote:
>>>> The algorithm computes level by level in the second pass (ie on its
>>>> way down) how the windows should be sized. So you have the sizes for
>>>> all windows on that level at once.
>>> I still don't understand what a "level" is.
>>
>> All children to a window are on the same level.
>
> So you want a routine to set the sizes of all children of a window?
> What would you want to pass to that routine?  A list?


Yes, but I am starting to wonder a bit what I really want. It looks to
me like I instead could use your new functions+remove restriction
check. See below.


>> Do I understand you right, do you say: These should set the size
>> without any checking.
>
> The new size of one window.  Applying the new sizes of all windows is
> done transactionally, all at once (or none at all if there's a failure).


There are some ideas here that are rather similar but differs a bit.
You and Stefan have been talking about the idea about treating the
size changes as transactions with possible roll back.

That seems ok to me. But I choosed a little bit different route. I am
trying to make the calculations first and only apply them if new sizes
fit. However with my idea there is still the problem of applying the
new sizes without bumping into any restriction during the applying
phase. This could happen even if you know that the final result will
fit.

That was the reason I asked for a function above to set the sizes of
all children at once. But such a function will not help since bumbing
into restrictions can happen further down the tree also.

So what I need is still a way to apply the new sizes without
restriction checks during that phase. Am I clear enough when I try to
explain this? How should I do to avoid the restrictions in this phase?


>> You can make a lisp copy of the configuration. This copy should
>> contain just the info needed to compute the new sizes. If you want the
>> sizes after deletion then just do not include the window you want to
>> delete in the copy.
>
> And who does delete the window _and_ resize the remaining ones?


You ... ;-)

Yes, I know that this is lacking. I have been wondering about this
part. It is not clear to me how resizing and deletion/creation of
windows are tighed together in the current code. I think those parts
should be broken up. Can you please try to explain how things are now
and if you see some way to brake those things apart?


>> I guessed there must be some pointer (in a general sense) for each
>> frame to the root window. I do not know the actual implementation, but
>> I just glanced at it. Unfortunately it takes some time for me to read
>> C so I guess a little. I can see there is a Lisp_Object called
>> root_window in struct frame. This is the pointer I am talking about.
>>
>> My question (and suggestion) to you is this: Would it be possible to
>> temporarily replace the frames root_window with a new window when the
>> frame size gets so small that the window configuration does not fit?
>> Whether this is easy (or perhaps even possible) is of course dependent
>> on the details in this implementation.
>>
>> It depends on for example on how drawing of windows are done. Is
>> drawing of a frame something that starts from the frame and then goes
>> down to look at the windows? Or does the windows live a life on their
>> on in this regard? I have assumed the former when I suggested to just
>> swap the roor_window pointer. You know more about the implementation
>> details and can probably give a better answer.
>
> It would get us into hell's kitchen to just swap some pointers.  The
> more so because you want redisplay to happen in between.  What do you
> think window-configurations have been invented for?


Window configurations was invented for this situation. It has a much
broader use.

But if you say it is impossible to switch this pointer then I surely
assume that you are right (since you know better about how the code
has been structured).

Then I assume that window configurations must be used to get my
suggestion to work. The drawback I see then is that window pointers
migh gets lost. Are there any way around that?


>> You seem to suggest that it would be hard to understand for the user.
>> In that case, why?
>
> Because at the time the window-manager shrinks my Emacs frame I usually
> want to work with some other application.


I am sorry, but I can't see why that should make it harder to
understand. The text to show can of course be changed to avoid some
confusion. Does not that help?


>>> You do undelete all the time.  It's completely transparent.
>>
>> How can it be transparent if windows disappears and reappears? I must
>> be misunderstanding you somehow...
>
> There might be no redisplay in between.


How can you avoid that when the frame gets too small?


>>>> - size-0 windows in a case like this would be the same.
>>> Many applications do that.
>>
>> Can you explain how you mean?
>
> In many applications (Thunderbird is one of them) I can make subwindows
> disappear completely by dragging one of their borders and make them
> reappear later by dragging on the border where they disappeared.


Are there no sign at all that there are 0-size windows there?


> martin
>