The parameter was already removed, I'm simply updating the documentation.

On Mon, Feb 10, 2014 at 4:41 PM, Bill Spitzak <spit...@gmail.com> wrote:

> I would think configure request is going to need to provide this
> information. Otherwise the compositor cannot do tabbed or tiled layouts
> were it wants a window to resize without the client requesting it.
>
> Then again perhaps it is ok for compositor-initiated resizing to always
> produce the same anchoring effect (ie whatever the client decides to do) so
> maybe this is ok. But I'm still concerned that it may be hard for a client
> to tell when resizing it initiated stops and other resizes start, so that
> it can change how it is handling the edges. Is this already solved in some
> other way?
>
>
> Jasper St. Pierre wrote:
>
>> The parameter was dropped...
>> ---
>>  protocol/xdg-shell.xml | 6 ------
>>  1 file changed, 6 deletions(-)
>>
>> diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml
>> index f0d04aa..7e4193b 100644
>> --- a/protocol/xdg-shell.xml
>> +++ b/protocol/xdg-shell.xml
>> @@ -243,12 +243,6 @@
>>         ignore it if it doesn't resize, pick a smaller size (to
>>         satisfy aspect ratio or resize in steps of NxM pixels).
>>  -      The edges parameter provides a hint about how the surface
>> -       was resized. The client may use this information to decide
>> -       how to adjust its content to the new size (e.g. a scrolling
>> -       area might adjust its content position to leave the viewable
>> -       content unmoved). Valid edge values are from resize_edge enum.
>> -
>>         The client is free to dismiss all but the last configure
>>         event it received.
>>
>>
>


-- 
  Jasper
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Reply via email to