Re: [PATCH v4 xdg-shell-unstable-v6] xdg-shell: add preferred min/max size requests

[Olivier Fourdan]

Hi Jonas,

> What is the point of making the max/min size just "preferred"? What are
> the use cases when compositor should ignore the hint?
> 
> I suppose one would be when a client sets a relatively small max size,
> but then asks to be maximized or fullscreened, forcing the compositor to
> ignore the hint, but then, why would that client ever set the relatively
> small max size if it wasn't any truth to it?

Here is the discussion:

https://people.freedesktop.org/~cbrill/dri-log/?channel=wayland_irssi=true_html=true_names=SardemFF7=2016-04-04

It starts at 9:49

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

Re: [PATCH v4 xdg-shell-unstable-v6] xdg-shell: add preferred min/max size requests

[Jonas Ådahl]

On Fri, Apr 08, 2016 at 02:42:53AM -0400, Olivier Fourdan wrote:
> Hi
> 
> > I see no reason for "preferred" to be in the name. There is no intention to
> > be able to ever specify a "real" min/max size so this word does not
> > distinguish the values from any thing else.
> 
> This was asked explicitly on irc #wayland last Monday (iirc) by SardemFF7.
> 
> This is not to distinguish from a "real" min/max size, this is intended to 
> make it very clear even in the request name that this is by no mean 
> enforceable by the client.
> 
> In other words, it's just a hint (just that we can't use hint as this is 
> dirty word nowadays ^_~)
> 
> > Also if these remain two calls, the compositor must allow the maximum to be
> > less than the minimum, at least temporarily between the calls.
> 
> I reckon this is the compositor implementation, not sure this should be in 
> the spec.

What is the point of making the max/min size just "preferred"? What are
the use cases when compositor should ignore the hint?

I suppose one would be when a client sets a relatively small max size,
but then asks to be maximized or fullscreened, forcing the compositor to
ignore the hint, but then, why would that client ever set the relatively
small max size if it wasn't any truth to it?


Jonas

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

Re: [PATCH v4 xdg-shell-unstable-v6] xdg-shell: add preferred min/max size requests

[Olivier Fourdan]

Hi

> I see no reason for "preferred" to be in the name. There is no intention to
> be able to ever specify a "real" min/max size so this word does not
> distinguish the values from any thing else.

This was asked explicitly on irc #wayland last Monday (iirc) by SardemFF7.

This is not to distinguish from a "real" min/max size, this is intended to make 
it very clear even in the request name that this is by no mean enforceable by 
the client.

In other words, it's just a hint (just that we can't use hint as this is dirty 
word nowadays ^_~)

> Also if these remain two calls, the compositor must allow the maximum to be
> less than the minimum, at least temporarily between the calls.

I reckon this is the compositor implementation, not sure this should be in the 
spec.

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

Re: [PATCH v4 xdg-shell-unstable-v6] xdg-shell: add preferred min/max size requests

[Olivier Fourdan]

Hi Yong,

- Original Message -
> Hi Olivier,
> Some minor spelling corrections below. (Same as the previous response,
> replying again to associate with this latest patch version.) I'm happy
> to correct these with my own separate patch after this is merged.
> 
> 
> > ---
> > 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 mutliple mismatch of min/max in the description
> 
> multiple

These are notes for the reviewers, they won't end up in the patch itself nor in 
the git log, so it doesn't really count.

The others do though, I'll fix these typos in my next iteration, I guess you 
can sense some sort of copy/paste pattern :)

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

Re: [PATCH v4 xdg-shell-unstable-v6] xdg-shell: add preferred min/max size requests

[Yong Bakos]

> On Apr 7, 2016, at 2:39 AM, Olivier Fourdan  wrote:
> 
> Some application may wish to restrict their window in size, but
> xdg-shell has no mechanism for the client to advertise such a maximum
> or minimum preferred size the compositor can use.
> 
> 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_preferred_max_size" and "set_preferred_min_size"
> to xdg-shell so that the client can tell the compositor which would be
> its preferred smallest/largest acceptable size, so that he compositor
> can decide if maximize or fullscreen makes sense, draw an accurate
> animation, etc.
> 
> Signed-off-by: Olivier Fourdan 
> Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413

Hi Olivier,
Some minor spelling corrections below. (Same as the previous response,
replying again to associate with this latest patch version.) I'm happy
to correct these with my own separate patch after this is merged.


> ---
> 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 mutliple mismatch of min/max in the description

multiple


> Remove mention of "unscaled", specify window geometry coordinates
> and refer to set_window_geometry.
> 
> 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..05f28f6 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 preferred maximum size for the window.
> +
> + The client can specify a preferred maximum size to tell the
> + compositor that a window should not be resized beyond this
> + size.
> +
> + The width and height arguments are in window geometry coordinates.
> + See set_window_geometry.
> +
> + The compositor may use this information from the client to allow
> + or disallow different states like maximixe or fullscreen and

maximize


> + draw accurate animations.
> +
> + Similarily, a tiling window manager can use this information to

Similarly,


> + place and resize client windows in a more effective way.
> +
> + If never set, the 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 preference regarding the maximum size
> + in the given dimension. As a result, a client wishing to reset the
> + preferred maximum size to an unspecified state can use zero for
> + width and height in the request.
> +  
> +  
> +  
> +
> +
> +
> +  
> + Set a preferred minimum size for the window.
> +
> + The client can specify a preferred minimum size to tell the
> + compositor that a window should not be resized below this
> + size.
> +
> + The width and height arguments are in window geometry coordinates.
> + See set_window_geometry.
> +
> + The compositor may use this information from the client to allow
> + or disallow different states like maximixe or fullscreen and

maximize


> + draw accurate animations.
> +
> + Similarily, a tiling window manager can use this information to

Similarly

yong


> + place and resize client windows in a more effective way.
> +
> + If never set, the 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 preference regarding the minimum size
> + in the given dimension. As a result, a client wishing to reset the
> + preferred 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