[PATCH wayland-protocols 00/11] Declaring xdg-shell stable

[Jonas Ådahl]

On Fri, Jun 02, 2017 at 09:54:31AM +0100, David Edmundson wrote:
> I have some comments/questions on the current v6 interface which I'd like
> clarifying before we make it stable.
> 
> The Positioner anchor and gravity both takes the edge as a bitfield of
> flags.
> 
> It's then part of the protocol to say "If two parallel anchor edges are
> specified (e.g. 'left' and 'right'), the invalid_input error is raised."
> 
> I don't understand why we don't use 9 enum values; none, topleft, top,
> topright etc. as it forbids even the possibility of an invalid input. It's
> what we do in the top level resize edge. It seems cleaner and safer wtih no
> drawbacks

That would indeed be equivalent. Would you create a patch on top of this
branch to update this for the future stable version?

> 
>  ----
> 
> Also on the positioner, when I have an offset from an anchor what is the
> intended behaviour in the compositor for applying this if I end up flipping
> or sliding due to constraints?

The idea is that the offset will be applied after placing given the
anchor rect, gravity and anchor, and then constrain adjusted. For
sliding, this means that the popup is first positioned, and moved on one
or two axes. For flipping, it's a bit more non straight forward, as
flipping and the offset are not very useful in combination, but my idea
of it is that after being constrain tested and a flip is triggered, the
new position of the popup is calculated again as before but with the
flipped gravity and anchor.

How about we add the following paragraph to the flip_x/y descriptions:

	  The adjusted position is calculated given the original anchor
	  rectangle and offset, but with the new flipped anchor and gravity
	  values.

For the slide_x/y description, I don't think its needed. The set_offset
request contains a note about the post-offset position is the one used
when constrain testing, and slide_x/y only talks about sliding the
surface position in case of constrain testing shows the surface is
constrained.

> Any user interface element isn't going to line up after it's constrained in
> the same axis as the offset...unless we allow clients to specify an offset
> for every possible constraint.

Could you elaborate on this? I'm not sure what you mean here. In what
way do you want to align a UI widget that is not supported?

Sorry for the delays btw, and thanks for the input!


Jonas

> 
> Regards
> 
> David