[PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Jonas Ådahl]

On Tue, Apr 12, 2016 at 08:05:03AM -0500, Yong Bakos wrote:
> On Apr 12, 2016, at 2:22 AM, Jonas Ådahl <jadahl at gmail.com> wrote:
> > 
> > On Tue, Apr 12, 2016 at 03:20:27AM -0400, Olivier Fourdan wrote:
> >> Hi Mike,
> >> 
> >> ----- Original Message -----
> >>> I think this should probably use uint instead of int for params since zero
> >>> is the "unset" number. Otherwise you have to write something about negative
> >>> sizes.
> >> 
> >> Reason I used "int" is because these are limits for size, which are expressed with int as well. "set_window_geometry" uses "int" and specifies that width and height must be greater than zero.
> >> 
> >> Similarly, the configure event uses "int" as well, not uint", and also use zero for a special case (zero means the client should decide its own dimension) so it made sense to me to remain consistent by using "int".
> >> 
> >> But I can switch to uint if everyone agrees.
> >> 
> >> Cheers,
> >> Olivier
> > 
> > I think using ints makes most sense. Lets not end up with a salad of
> > different signedness for the same thing.
> > 
> > 
> > Jonas
> 
> Just wanted to say that everyone's comments on this thread have been
> educational for me, especially regarding the review process. I agree that
> ints should be used since uints have not been used for width/height parameters
> elsewhere in the Wayland core protocol.
> 
> But this begs a question, and please forgive my naïveté. Why aren't the
> width/height arguments in the core protocol unsigned? Wouldn't this afford us
> a little more type safety?

Because if x/y are ints and the x's and y's often needs to be combined
mathematically with the width's and height's. If we'd use different
signedness it'd be more error prone and confusing.

> 
> I also think that Bill's prior comment about min/max conflicts, despite double-
> buffering, may deserve some attention in the documentation. In other words,
> what does happen when the min and max conflict? Is it undefined, or should the
> protocol state that the compositor should ignore such a conflict?

Good point. Setting an invalid state should probably result in a
protocol error.


Jonas

> 
> yong
>