[Weston] More discussion about weston output relative motion algorithm

[Wang, Quanxian]

Hi, Pq

> 
> I meant this very simple example:
> 
> There is only one output A.
> 
> A
> 
> Then I add output B to the left of A.
> 
> B->A
> 
> The position of A must not change. This means that B must get negative
> coordinates, and A's position stays at 0,0. In Weston, window positions are
> stored in global coordinates, and to keep windows that were on output A,
> still on output A, the position of A must not change.
[Wang, Quanxian] This case is a special case, from it, you could not find the principle. Because in this case, you have the choice 'A must not change' or 'A must change'.
But for C->B->A, it will be very clear why we follow the principle.
We must think about how to make the principle to be accepted anywhere instead of special case. If we randomly define the rule, will make everything complex. It is not what we want.
By the way, when moving output, the move event will be sent to windows in this output. The window will be moved at the same time. 
> 
> Note, that you cannot infer this from the syntax "B->A", but you can from
> "put B left-of A": B is being set and A is the reference point.
> 
> 
> Another case:
> 
> First we have
> A->B
> 
> Then "add C right-of A".
> 
> Now you could get the chain A->C->B, or C could end up cloning B. I do not
> care too much on what happens there, since it is sort of ill-defined. But I do
> care about the first case where we are not adding in the middle.
> 
> > Now you get the principle from simple link. And then vlink is the same
> > thing. And then combine vlink and hlink together. At last I got this
> > algorithm. I know principle will exist in both complex and simple
> > layout. The algorithm can be summarized from them. Therefore my first
> > step is to study simple case and find what the rule is. And then turn
> > to complex and enhance the algorithm. Make the algorithm to be
> > complete.
> >
> > Here I list several questions for you.
> > 1) Why use tree to link all outputs together?
> > If just use coordinate to calculated the x, y, you will be lost.
> > Because when you moving output, you can't avoid affecting the position
> > of other outputs. You have to review all coordinates of outputs and
> > make decision who is left, right, above, below. It will be much more
> > complex. But if you use tree to link all, everything is very clear.
> > Who is left, right, above, below. It is very clear.
> > Coordinate and relative motion could be easily figured out.
> >
> > It will be very easy to control the position and movement of outputs.
> 
> My alternate proposition was to keep the ordered list of configuration
> directives instead of a tree structure. Not just x,y for each live output.
> 
> Instead of going through the tree to assing new positions, you would
> execute the list of directives.
> 
> You would also need some additional rule on where to add outputs that are
> not placed by any directive. Most likely this rule would just create directives
> for the outputs.
> 
> Whether that would work or not, I am not sure.
> 
> > 2) Why one root
> > One root will tell you, this is the top left most. No other outputs
> > will be left or above it. From this, you can calculate and review all
> > outputs. No one is lost.
> 
> Your definition of top-left most causes you to have problems in realizing an
> arrangement where the top-left output does not exist, e.g.:
> 
> - C
> B A
> 
> OTOH with directives, there is no need to define a root output.
> 
> Directives could also refer to inactive outputs. Inactive outputs would simply
> have zero size, and the directive would be executed as always.
[Wang, Quanxian] Let me think about that case. In current algorithm, this case will not happen. The algorithm design will avoid such condition. But in practice, this layout really exists.
The solution could be:
Root output should exist because it will link all outputs. We really need that.  But I like you suggestion to make root virtual (just as you said, zero size). At the same time we can define gap for every output. In this case, C'x coordinate will have this gap.
So the link could be 
Root->hlink = C (x's gap is x)
Root->vlink = B  (y's gap is y)
C->vlink = A or B->hlink = A.

Is it reasonable? :)

If so, pos(x,y) will take into consideration.
But you definitely can not define such case
B->hlink = A
C->vlink = A
If you has such case, it will crash all. A can't have two parent because it will cause conflict of A's coordinate.
> 
> > 3) Why only one parent?
> > If two parents, you will find more links will cross each other. It is
> > absolutely a disaster. (This could cause conflict of coordinates, from
> > this path, it will A, for that path, it will B. A and B is not
> > same.)
> >
> > I am not sure if you understand my idea. Sorry for my poor language.
> 
> No, I do understand the tree structure well. It is just the rationale behind
> that is unclear, it clearly has some reasonable cases it cannot represent, and
> some IMO surprising behaviour.
> 
> 
> Thanks,
> pq
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel