Re: New balance-windows

[Lennart Borgman <lennart.borgman.073@student.lu.se>]

Pascal Bourguignon wrote:

>>>File: elisp,  Node: Window Internals
>>>
>>>      
>>>
>>Thanks, I did not know this was available. Then the windows in each
>>frame can be seen as a tree using those fields you mentioned. But what
>>should then be done with this? What should the mapping between this
>>tree and the visual view be? It looks to me that the level in the tree
>>alone will not give any useful hint. The topology (ie whether the
>>splitting was horizontal or vertical) must be taken into account, but
>>maybe the level in the tree can be used too? It actually looks a bit
>>difficult...
>>    
>>
>
>Well, it's only available to the C programmer...
>  
>
I noticed when I tried to implement the algorithm I suggested. However 
it should be possible to find the split tree with a bit of work. It may 
fail when window borders meat each like a + so to say, but maybe trying 
to change the window sizes can resolve such cases. So I was wrong I 
think. It is not absolutely necessary to have the access to those hchild 
etc.

I guess you are counting the children in each sub tree (something 
similar to what I suggested though you may not have read that)? Maybe it 
should be good with some weights for a user to customize?

Finding the split tree is a bit tricky to say the least. You have to 
imagine a split tree and start to pick up the windows from the leafs and 
work upwards. Maybe thinking in sets helps? There are certain cases 
where you can not know how the split tree actually was (like three 
windows above each other), but from a user perspective those are perhaps 
better handled as a node with three childs whether that is the case in 
the internal split tree or not. (Perhaps this shows that it is better 
not to use the internal split tree?)