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

2016-04-18 Thread Bill Spitzak 

On 04/12/2016 06:10 AM, Jonas Ådahl wrote:


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


No this cannot be a protocol error because that makes it difficult to 
change the size range to a new one that does not intersect the old one.


Perhaps having the commit of an invalid state be a protocol error is ok.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

2016-04-13 Thread Olivier Fourdan 
Hi Bill,

> 
> > > It allows a client to say "I look best below this size, but if the
> > > compositor wants to fill a larger rectangle, I can draw something nicer
> > > than the compositor can do (the compositor can only pad or scale)".
> >
> > That's something different, isn't it? The compositor sending a configure
> > event and the size specified there must be obeyed by the client (as
> > specified in the spec for maximize and fullscreen state, but the point of
> > using min/max is precisely to let the compositor know that such states are
> > not desirable for that given surface).
> 
> Clients do not have to obey the requested size by the compositor.

The spec reads, for state maximized and fullscreen:


  
  [...]
  

  The surface is maximized. The window geometry specified in the 
configure
  event must be obeyed by the client.

  
  

  The surface is fullscreen. The window geometry specified in the 
configure
  event must be obeyed by the client.

  
  [...]


That's 
https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/xdg-shell/xdg-shell-unstable-v5.xml#n343
 
> This is
> how min/max size was being done previously, and how size increments and
> aspect ratios and any other client restrictions on possible size are still
> being done now.

I know. So either the description above is incorrect, or I don't understand 
what "must be obeyed" means in this context.

BTW, that's precisely the patches I wrote for gtk+ for fullscreen and 
maximized, ignore the size increments and now max size when receiving a 
configure event with state maximized or fullscreen.

For reference, that was:

https://bugzilla.gnome.org/show_bug.cgi?id=751368

and now

https://bugzilla.gnome.org/show_bug.cgi?id=764413

> I don't think clients should have to obey fullscreen either, though I'm not
> sure what the documentation says. The compositor can just center the
> surface above black if the client does not resize it, this functionality is
> already supported.

Correct, for fullscreen, this is the case, this is where I think the spec gets 
a tad confusing imho:

https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/xdg-shell/xdg-shell-unstable-v5.xml#n508


  
Make the surface fullscreen.

You can specify an output that you would prefer to be fullscreen.
If this value is NULL, it's up to the compositor to choose which
display will be used to map this surface.

If the surface doesn't cover the whole output, the compositor will
position the surface in the center of the output and compensate with
black borders filling the rest of the output.
  
  


So the client must obey the window geometry specified in the configure event 
when the state is fullscreen, but the surface may not cover the whole output.

> [...]
> 
> > My point was more about the client itself setting min/max and then setting
> > a geometry that falls outside of the limits it sets itself, I reckon that
> > should be a protocol error, the client is sending incompatible requests to
> > the compositor.
> 
> 
> No this absolutely must not be a protocol error.
> 
> *maybe* it could be a protocol error to resize larger than the maximum of
> the current maximum size and the configure request that it is responding
> to, but this is going to lead to synchronization issues since there is no
> serial number indicating the configure request it is processing. And it may
> even have to add a good deal of fudge factor so a client can continue to
> round to size increments. So even this idea looks very difficult and
> pointless to handle.

Yes, I agree, the client can set a geometry following a configure request, and 
that must respect the window geometry specified by the states in the configure 
events, which must be obeyed:

https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/xdg-shell/xdg-shell-unstable-v5.xml#n450


  
The window geometry of a window is its "visible bounds" from the
user's perspective. Client-side decorations often have invisible
portions like drop-shadows which should be ignored for the
purposes of aligning, placing and constraining windows.

[...]

If responding to a configure event, the window geometry in here
must respect the sizing negotiations specified by the states in
the configure event.

[...]
  

So I think we should clarify the "must be obeyed" part of the configure event 
when state is maximized or fullscreen.

Cheers,
Olivier
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

2016-04-12 Thread The Rasterman 
On Tue, 12 Apr 2016 15:25:36 + Mike Blumenkrantz
 said:

> Sure, that sounds good to me!

i like the idea of keeping < 0 invalid for now... it leaves wiggle room in
future to maybe make it valid and have special meaning but for now is invalid
thus can be assumed to not be used.

> On Tue, Apr 12, 2016 at 11:24 AM Olivier Fourdan 
> wrote:
> 
> > Hi Mike.
> >
> > > Okay, if we're not going with uints then at the least can the "use 0 to
> > > unset min/max" be changed to "use <= 0 to unset min/max" to explicitly
> > > cover that case?
> >
> > I think we should simply indicate that the width and height must be
> > greater than or equal to zero, so we remain consistent with the other
> > descriptions (namely set_window_geometry).
> >
> > Then we could also state that using strictly negative values would raise a
> > protocol error?
> >
> > Cheers,
> > Olivier
> >


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

2016-04-12 Thread Olivier Fourdan 
> On 04/12/2016 08:17 AM, Olivier Fourdan wrote:
> [...]
> >
> > But that raise another point, what if the client itself specifies a
> > geometry (using set_window_geometry) outside of the min/max?
> >
> > I reckon that would be a protocol error as well. if so, I guess it means I
> > have to update the descriptions of set_window_geometry accordingly.
> 
> No, that is explicitly allowed.
> 
> It allows a client to say "I look best below this size, but if the
> compositor wants to fill a larger rectangle, I can draw something nicer
> than the compositor can do (the compositor can only pad or scale)".

That's something different, isn't it? The compositor sending a configure event 
and the size specified there must be obeyed by the client (as specified in the 
spec for maximize and fullscreen state, but the point of using min/max is 
precisely to let the compositor know that such states are not desirable for 
that given surface).

If the compositor insist of maximizing a window that has set a max size smaller 
than the output, then yes, the client must obey.a

> An example is a calculator that may want to continue expanding the
> output text area, while restricting the size of the buttons.

Err, that's the internal layout of the app, not something xdg-shell would 
interfere with, or I misunderstand you?

My point was more about the client itself setting min/max and then setting a 
geometry that falls outside of the limits it sets itself, I reckon that should 
be a protocol error, the client is sending incompatible requests to the 
compositor.

Cheers,
Olivier
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

2016-04-12 Thread Mike Blumenkrantz 
Sure, that sounds good to me!

On Tue, Apr 12, 2016 at 11:24 AM Olivier Fourdan 
wrote:

> Hi Mike.
>
> > Okay, if we're not going with uints then at the least can the "use 0 to
> > unset min/max" be changed to "use <= 0 to unset min/max" to explicitly
> > cover that case?
>
> I think we should simply indicate that the width and height must be
> greater than or equal to zero, so we remain consistent with the other
> descriptions (namely set_window_geometry).
>
> Then we could also state that using strictly negative values would raise a
> protocol error?
>
> Cheers,
> Olivier
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

2016-04-12 Thread Olivier Fourdan 
Hi Mike.

> Okay, if we're not going with uints then at the least can the "use 0 to
> unset min/max" be changed to "use <= 0 to unset min/max" to explicitly
> cover that case?

I think we should simply indicate that the width and height must be greater 
than or equal to zero, so we remain consistent with the other descriptions 
(namely set_window_geometry).

Then we could also state that using strictly negative values would raise a 
protocol error?

Cheers,
Olivier
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

2016-04-12 Thread Olivier Fourdan 
> > > Good point. Setting an invalid state should probably result in a
> > > protocol error.
> > 
> > No this cannot be a protocol error because that makes it difficult to
> > change the size range to a new one that does not intersect the old one.
> > 
> > Perhaps having the commit of an invalid state be a protocol error is ok.
> 
> We'd reach an invalid state only once it's applied, ie after the commit.
> 
> So the client can (and must) set a Min <= Max before the commit, otherwise
> it's an invalid state that will lead to a protocol error.
> 
> That's what I've tried to specify in v6:
> 
>   Values set in this way are double-buffered. They will get applied
>   on the next commit.
> 
>   [...]
> 
>   Requesting a minimum size to be larger than the maximum size of
>   a surface is illegal and will result in a protocol error.

But that raise another point, what if the client itself specifies a geometry 
(using set_window_geometry) outside of the min/max?

I reckon that would be a protocol error as well. if so, I guess it means I have 
to update the descriptions of set_window_geometry accordingly.

Cheers,
Olivier
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

2016-04-12 Thread Mike Blumenkrantz 
Okay, if we're not going with uints then at the least can the "use 0 to
unset min/max" be changed to "use <= 0 to unset min/max" to explicitly
cover that case?

On Tue, Apr 12, 2016 at 10:40 AM Olivier Fourdan 
wrote:

> Hi,
>
>
> > > Good point. Setting an invalid state should probably result in a
> > > protocol error.
> >
> > No this cannot be a protocol error because that makes it difficult to
> > change the size range to a new one that does not intersect the old one.
> >
> > Perhaps having the commit of an invalid state be a protocol error is ok.
>
> We'd reach an invalid state only once it's applied, ie after the commit.
>
> So the client can (and must) set a Min <= Max before the commit, otherwise
> it's an invalid state that will lead to a protocol error.
>
> That's what I've tried to specify in v6:
>
> Values set in this way are double-buffered. They will get applied
> on the next commit.
>
> [...]
>
> Requesting a minimum size to be larger than the maximum size of
> a surface is illegal and will result in a protocol error.
>
> Cheers,
> Olivier
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

2016-04-12 Thread Olivier Fourdan 
Hi,


> > Good point. Setting an invalid state should probably result in a
> > protocol error.
> 
> No this cannot be a protocol error because that makes it difficult to
> change the size range to a new one that does not intersect the old one.
> 
> Perhaps having the commit of an invalid state be a protocol error is ok.

We'd reach an invalid state only once it's applied, ie after the commit.

So the client can (and must) set a Min <= Max before the commit, otherwise it's 
an invalid state that will lead to a protocol error.

That's what I've tried to specify in v6:

Values set in this way are double-buffered. They will get applied
on the next commit.

[...]

Requesting a minimum size to be larger than the maximum size of
a surface is illegal and will result in a protocol error.

Cheers,
Olivier
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

2016-04-12 Thread Yong Bakos 
On Apr 12, 2016, at 2:22 AM, Jonas Ådahl  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?

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?

yong

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

2016-04-12 Thread 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  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
> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

2016-04-12 Thread Olivier Fourdan 

Hi Jasper,

- Original Message -
> I figured min/max would be double-buffered state and require a commit
> to take affect. In fact, anything else means that we can't extend with
> additional size constraints in the future, since they couldn't be
> applied atomically.

Completely agree, I'll add a note similar to the one from "set_window_geometry" 
to make it clear it's double-buffered and applied on the next commit.

Cheers,
Olivier
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

2016-04-12 Thread Jonas Ådahl 
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.

I think using ints makes most sense. Lets not end up with a salad of
different signedness for the same thing.


Jonas

> 
> Cheers,
> Olivier
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

2016-04-12 Thread Olivier Fourdan 
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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

2016-04-11 Thread Mike Blumenkrantz 
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.

On Mon, Apr 11, 2016 at 3:11 PM Jasper St. Pierre 
wrote:

> On Mon, Apr 11, 2016 at 12:59 AM, Olivier Fourdan 
> wrote:
> > Some application may wish to restrict their window in size, but
> > xdg-shell has no mechanism for the client to specify a maximum or
> > minimum size.
> >
> > As a result, the compositor may try to maximize or fullscreen a window
> > while the client would not allow for the requested size.
> >
> > Add new requests "set_max_size" and "set_min_size" to xdg-shell so that
> > the client can tell the compositor what would be its smallest/largest
> > acceptable size, and that the compositor can decide if maximize or
> > fullscreen is achievable, draw an accurate animation, etc.
> >
> > Signed-off-by: Olivier Fourdan 
> > Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413
> > ---
> >  v2: Rename the request to "set_preferred_max_size",
> >  add "set_preferred_min_size" as well
> >  v3: Rebase above patch 72427 in branch xdg-shell-unstable-v6
> >  Rephrase description to clarify the unscaled size and using 0 to
> >  reset back the preferred size to an unspecified state
> >  v4: Patch the correct xml file (v6, not v5 )
> >  Fix multiple mismatch of min/max in the description
> >  Remove mention of "unscaled", specify window geometry coordinates
> >  and refer to set_window_geometry.
> >  v5: Fix typos and remove "preferred" from the name and description as
> >  requested by several people on the ML and irc.
> >
> >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 60
> 
> >  1 file changed, 60 insertions(+)
> >
> > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > index 3fc7d42..8ab84f5 100644
> > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > @@ -489,6 +489,66 @@
> >
> >  
> >
> > +
> > +  
> > +   Set a maximum size for the window.
> > +
> > +   The client can specify a maximum size so that the compositor does
> > +   not try to configure the window beyond this size.
> > +
> > +   The width and height arguments are in window geometry
> coordinates.
> > +   See set_window_geometry.
> > +
> > +   The compositor can use this information to allow or disallow
> > +   different states like maximize or fullscreen and draw accurate
> > +   animations.
> > +
> > +   Similarly, a tiling window manager may use this information to
> > +   place and resize client windows in a more effective way.
> > +
> > +   If never set, the maximum size of the window is not limited by
> > +   the client.
>
> Delete this sentence, and merge it into the paragraph below.
>
> > +   A value of zero in the request for either width, height or both
> > +   means that the client has no expected maximum size in the given
> > +   dimension. As a result, a client wishing to reset the maximum
> size
> > +   to an unspecified state can use zero for width and height in the
> > +   request.
>
> If never set, or a value of zero in the request, means that the client
> has no expected...
>
> > +  
> > +  
> > +  
> > +
> > +
> > +
> > +  
> > +   Set a minimum size for the window.
> > +
> > +   The client can specify a minimum size so that the compositor does
> > +   not try to configure the window below this size.
> > +
> > +   The width and height arguments are in window geometry
> coordinates.
> > +   See set_window_geometry.
> > +
> > +   The compositor can use this information to allow or disallow
> > +   different states like maximize or fullscreen and draw accurate
> > +   animations.
> > +
> > +   Similarly, a tiling window manager may use this information to
> > +   place and resize client windows in a more effective way.
> > +
> > +   If never set, the minimum size of the window is not limited by
> > +   the client.
> > +
> > +   A value of zero in the request for either width, height or both
> > +   means that the client has no expected minimum size in the given
> > +   dimension. As a result, a client wishing to reset the minimum
> size
> > +   to an unspecified state can use zero for width and height in the
> > +   request.
> > +  
> > +  
> > +  
> > +
> > +
> >  
> >
> > Maximize the surface.
> > --
> > 2.5.5
> >
>
>
>
> --
>   Jasper
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list

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

2016-04-11 Thread Jasper St. Pierre 
On Mon, Apr 11, 2016 at 12:59 AM, Olivier Fourdan  wrote:
> Some application may wish to restrict their window in size, but
> xdg-shell has no mechanism for the client to specify a maximum or
> minimum size.
>
> As a result, the compositor may try to maximize or fullscreen a window
> while the client would not allow for the requested size.
>
> Add new requests "set_max_size" and "set_min_size" to xdg-shell so that
> the client can tell the compositor what would be its smallest/largest
> acceptable size, and that the compositor can decide if maximize or
> fullscreen is achievable, draw an accurate animation, etc.
>
> Signed-off-by: Olivier Fourdan 
> Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413
> ---
>  v2: Rename the request to "set_preferred_max_size",
>  add "set_preferred_min_size" as well
>  v3: Rebase above patch 72427 in branch xdg-shell-unstable-v6
>  Rephrase description to clarify the unscaled size and using 0 to
>  reset back the preferred size to an unspecified state
>  v4: Patch the correct xml file (v6, not v5 )
>  Fix multiple mismatch of min/max in the description
>  Remove mention of "unscaled", specify window geometry coordinates
>  and refer to set_window_geometry.
>  v5: Fix typos and remove "preferred" from the name and description as
>  requested by several people on the ML and irc.
>
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 60 
> 
>  1 file changed, 60 insertions(+)
>
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index 3fc7d42..8ab84f5 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -489,6 +489,66 @@
>
>  
>
> +
> +  
> +   Set a maximum size for the window.
> +
> +   The client can specify a maximum size so that the compositor does
> +   not try to configure the window beyond this size.
> +
> +   The width and height arguments are in window geometry coordinates.
> +   See set_window_geometry.
> +
> +   The compositor can use this information to allow or disallow
> +   different states like maximize or fullscreen and draw accurate
> +   animations.
> +
> +   Similarly, a tiling window manager may use this information to
> +   place and resize client windows in a more effective way.
> +
> +   If never set, the maximum size of the window is not limited by
> +   the client.

Delete this sentence, and merge it into the paragraph below.

> +   A value of zero in the request for either width, height or both
> +   means that the client has no expected maximum size in the given
> +   dimension. As a result, a client wishing to reset the maximum size
> +   to an unspecified state can use zero for width and height in the
> +   request.

If never set, or a value of zero in the request, means that the client
has no expected...

> +  
> +  
> +  
> +
> +
> +
> +  
> +   Set a minimum size for the window.
> +
> +   The client can specify a minimum size so that the compositor does
> +   not try to configure the window below this size.
> +
> +   The width and height arguments are in window geometry coordinates.
> +   See set_window_geometry.
> +
> +   The compositor can use this information to allow or disallow
> +   different states like maximize or fullscreen and draw accurate
> +   animations.
> +
> +   Similarly, a tiling window manager may use this information to
> +   place and resize client windows in a more effective way.
> +
> +   If never set, the minimum size of the window is not limited by
> +   the client.
> +
> +   A value of zero in the request for either width, height or both
> +   means that the client has no expected minimum size in the given
> +   dimension. As a result, a client wishing to reset the minimum size
> +   to an unspecified state can use zero for width and height in the
> +   request.
> +  
> +  
> +  
> +
> +
>  
>
> Maximize the surface.
> --
> 2.5.5
>



-- 
  Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

2016-04-11 Thread Jasper St. Pierre 
I figured min/max would be double-buffered state and require a commit
to take affect. In fact, anything else means that we can't extend with
additional size constraints in the future, since they couldn't be
applied atomically.

On Mon, Apr 11, 2016 at 12:02 PM, Bill Spitzak  wrote:
> Because of the two requests, the compositor can at least momentarily be in a
> state where max < min (otherwise it is impossible for a client to change the
> size range to a new one that does not intersect the old one). May want to
> specify what happens in this case. In particular it is required that setting
> the max does not change the min and vice-versa. And if max as though both values are equal to max, min, (max+min)/2, or what (my
> recommendation is to use min).
>
> Then again the above may be considered obvious and I am worried about
> nothing, in which case the current documentation is just fine.
>
>
> On Mon, Apr 11, 2016 at 5:23 AM, Yong Bakos  wrote:
>>
>> On Apr 11, 2016, at 2:59 AM, Olivier Fourdan  wrote:
>> >
>> > Some application may wish to restrict their window in size, but
>> > xdg-shell has no mechanism for the client to specify a maximum or
>> > minimum size.
>> >
>> > As a result, the compositor may try to maximize or fullscreen a window
>> > while the client would not allow for the requested size.
>> >
>> > Add new requests "set_max_size" and "set_min_size" to xdg-shell so that
>> > the client can tell the compositor what would be its smallest/largest
>> > acceptable size, and that the compositor can decide if maximize or
>> > fullscreen is achievable, draw an accurate animation, etc.
>> >
>> > Signed-off-by: Olivier Fourdan 
>> > Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413
>>
>> Looks good to me. (Note: I'm a novice reviewer.)
>>
>> Reviewed-by: Yong Bakos 
>>
>> yong
>>
>>
>> > ---
>> > v2: Rename the request to "set_preferred_max_size",
>> > add "set_preferred_min_size" as well
>> > v3: Rebase above patch 72427 in branch xdg-shell-unstable-v6
>> > Rephrase description to clarify the unscaled size and using 0 to
>> > reset back the preferred size to an unspecified state
>> > v4: Patch the correct xml file (v6, not v5 )
>> > Fix multiple mismatch of min/max in the description
>> > Remove mention of "unscaled", specify window geometry coordinates
>> > and refer to set_window_geometry.
>> > v5: Fix typos and remove "preferred" from the name and description as
>> > requested by several people on the ML and irc.
>> >
>> > unstable/xdg-shell/xdg-shell-unstable-v6.xml | 60
>> > 
>> > 1 file changed, 60 insertions(+)
>> >
>> > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>> > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>> > index 3fc7d42..8ab84f5 100644
>> > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>> > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>> > @@ -489,6 +489,66 @@
>> >   
>> > 
>> >
>> > +
>> > +  
>> > + Set a maximum size for the window.
>> > +
>> > + The client can specify a maximum size so that the compositor does
>> > + not try to configure the window beyond this size.
>> > +
>> > + The width and height arguments are in window geometry coordinates.
>> > + See set_window_geometry.
>> > +
>> > + The compositor can use this information to allow or disallow
>> > + different states like maximize or fullscreen and draw accurate
>> > + animations.
>> > +
>> > + Similarly, a tiling window manager may use this information to
>> > + place and resize client windows in a more effective way.
>> > +
>> > + If never set, the maximum size of the window is not limited by
>> > + the client.
>> > +
>> > + A value of zero in the request for either width, height or both
>> > + means that the client has no expected maximum size in the given
>> > + dimension. As a result, a client wishing to reset the maximum size
>> > + to an unspecified state can use zero for width and height in the
>> > + request.
>> > +  
>> > +  
>> > +  
>> > +
>> > +
>> > +
>> > +  
>> > + Set a minimum size for the window.
>> > +
>> > + The client can specify a minimum size so that the compositor does
>> > + not try to configure the window below this size.
>> > +
>> > + The width and height arguments are in window geometry coordinates.
>> > + See set_window_geometry.
>> > +
>> > + The compositor can use this information to allow or disallow
>> > + different states like maximize or fullscreen and draw accurate
>> > + animations.
>> > +
>> > + Similarly, a tiling window manager may use this information to
>> > + place and resize client windows in a more effective way.
>> > +
>> > + If never set, the minimum size of the window is not limited by
>> > + the client.
>> > +
>> > +

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

2016-04-11 Thread Yong Bakos 
On Apr 11, 2016, at 2:59 AM, Olivier Fourdan  wrote:
> 
> Some application may wish to restrict their window in size, but
> xdg-shell has no mechanism for the client to specify a maximum or
> minimum size.
> 
> As a result, the compositor may try to maximize or fullscreen a window
> while the client would not allow for the requested size.
> 
> Add new requests "set_max_size" and "set_min_size" to xdg-shell so that
> the client can tell the compositor what would be its smallest/largest
> acceptable size, and that the compositor can decide if maximize or
> fullscreen is achievable, draw an accurate animation, etc.
> 
> Signed-off-by: Olivier Fourdan 
> Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413

Looks good to me. (Note: I'm a novice reviewer.)

Reviewed-by: Yong Bakos 

yong


> ---
> v2: Rename the request to "set_preferred_max_size",
> add "set_preferred_min_size" as well
> v3: Rebase above patch 72427 in branch xdg-shell-unstable-v6
> Rephrase description to clarify the unscaled size and using 0 to
> reset back the preferred size to an unspecified state
> v4: Patch the correct xml file (v6, not v5 )
> Fix multiple mismatch of min/max in the description
> Remove mention of "unscaled", specify window geometry coordinates
> and refer to set_window_geometry.
> v5: Fix typos and remove "preferred" from the name and description as
> requested by several people on the ML and irc.
> 
> unstable/xdg-shell/xdg-shell-unstable-v6.xml | 60 
> 1 file changed, 60 insertions(+)
> 
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index 3fc7d42..8ab84f5 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -489,6 +489,66 @@
>   
> 
> 
> +
> +  
> + Set a maximum size for the window.
> +
> + The client can specify a maximum size so that the compositor does
> + not try to configure the window beyond this size.
> +
> + The width and height arguments are in window geometry coordinates.
> + See set_window_geometry.
> +
> + The compositor can use this information to allow or disallow
> + different states like maximize or fullscreen and draw accurate
> + animations.
> +
> + Similarly, a tiling window manager may use this information to
> + place and resize client windows in a more effective way.
> +
> + If never set, the maximum size of the window is not limited by
> + the client.
> +
> + A value of zero in the request for either width, height or both
> + means that the client has no expected maximum size in the given
> + dimension. As a result, a client wishing to reset the maximum size
> + to an unspecified state can use zero for width and height in the
> + request.
> +  
> +  
> +  
> +
> +
> +
> +  
> + Set a minimum size for the window.
> +
> + The client can specify a minimum size so that the compositor does
> + not try to configure the window below this size.
> +
> + The width and height arguments are in window geometry coordinates.
> + See set_window_geometry.
> +
> + The compositor can use this information to allow or disallow
> + different states like maximize or fullscreen and draw accurate
> + animations.
> +
> + Similarly, a tiling window manager may use this information to
> + place and resize client windows in a more effective way.
> +
> + If never set, the minimum size of the window is not limited by
> + the client.
> +
> + A value of zero in the request for either width, height or both
> + means that the client has no expected minimum size in the given
> + dimension. As a result, a client wishing to reset the minimum size
> + to an unspecified state can use zero for width and height in the
> + request.
> +  
> +  
> +  
> +
> +
> 
>   
>   Maximize the surface.
> -- 
> 2.5.5
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

2016-04-11 Thread Olivier Fourdan 
Some application may wish to restrict their window in size, but
xdg-shell has no mechanism for the client to specify a maximum or
minimum size.

As a result, the compositor may try to maximize or fullscreen a window
while the client would not allow for the requested size.

Add new requests "set_max_size" and "set_min_size" to xdg-shell so that
the client can tell the compositor what would be its smallest/largest
acceptable size, and that the compositor can decide if maximize or
fullscreen is achievable, draw an accurate animation, etc.

Signed-off-by: Olivier Fourdan 
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413
---
 v2: Rename the request to "set_preferred_max_size",
 add "set_preferred_min_size" as well
 v3: Rebase above patch 72427 in branch xdg-shell-unstable-v6
 Rephrase description to clarify the unscaled size and using 0 to
 reset back the preferred size to an unspecified state
 v4: Patch the correct xml file (v6, not v5 )
 Fix multiple mismatch of min/max in the description
 Remove mention of "unscaled", specify window geometry coordinates
 and refer to set_window_geometry.
 v5: Fix typos and remove "preferred" from the name and description as
 requested by several people on the ML and irc.

 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 60 
 1 file changed, 60 insertions(+)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index 3fc7d42..8ab84f5 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -489,6 +489,66 @@
   
 
 
+
+  
+   Set a maximum size for the window.
+
+   The client can specify a maximum size so that the compositor does
+   not try to configure the window beyond this size.
+
+   The width and height arguments are in window geometry coordinates.
+   See set_window_geometry.
+
+   The compositor can use this information to allow or disallow
+   different states like maximize or fullscreen and draw accurate
+   animations.
+
+   Similarly, a tiling window manager may use this information to
+   place and resize client windows in a more effective way.
+
+   If never set, the maximum size of the window is not limited by
+   the client.
+
+   A value of zero in the request for either width, height or both
+   means that the client has no expected maximum size in the given
+   dimension. As a result, a client wishing to reset the maximum size
+   to an unspecified state can use zero for width and height in the
+   request.
+  
+  
+  
+
+
+
+  
+   Set a minimum size for the window.
+
+   The client can specify a minimum size so that the compositor does
+   not try to configure the window below this size.
+
+   The width and height arguments are in window geometry coordinates.
+   See set_window_geometry.
+
+   The compositor can use this information to allow or disallow
+   different states like maximize or fullscreen and draw accurate
+   animations.
+
+   Similarly, a tiling window manager may use this information to
+   place and resize client windows in a more effective way.
+
+   If never set, the minimum size of the window is not limited by
+   the client.
+
+   A value of zero in the request for either width, height or both
+   means that the client has no expected minimum size in the given
+   dimension. As a result, a client wishing to reset the minimum size
+   to an unspecified state can use zero for width and height in the
+   request.
+  
+  
+  
+
+
 
   
Maximize the surface.
-- 
2.5.5

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel