[PATCH wayland-protocols] xdg-shell: Introduce xdg_toplevel capabilities

[Jonas Ådahl]

On Wed, Jul 20, 2016 at 11:12:03AM +0200, Quentin Glidic wrote:
> On 15/07/2016 13:00, Jonas Ådahl wrote:
> > The xdg_toplevel capabilities are meant to let the compositor know what
> > configurations a client can be configured to. This is meant to make it
> > possible to disallow a compositor to maximize, fullscreen etc a
> > surface, which would otherwise mandate the client to configure the
> > surface according to dimension in the xdg_toplevel.configure event.
> > 
> > This makes it possible to create non-resizable surfaces as well as
> > surfaces with only a certain aspect ratio allowed, by making them
> > un-fullscreen:able and un-maximize:able.
> > 
> > Signed-off-by: Jonas Ådahl <jadahl at gmail.com>
> > ---
> > 
> > This is an alternative solution to the s/must/should/ patch.
> > 
> > I made a separate enum, because certain state enum entries make no sense to
> > support or not, since they don't mandate anything (resize, activated so far).
> > 
> 
> I like this idea better than the s/must/should/ patch.
> 
> Since we do not reuse the existing enum, does that make sense to group
> similar features?
> The fullscreen/maximized/tiled states are about obeying an arbitrary size,
> you can still support even if you do nothing more. Sure, a fullscreen
> surface would look weird with a title bar, but it is usable, and will be on
> top of everything, just like intended.
> Thoughts?

Hmm. A 'can-be-force-resized' capability might be better indeed. It'd
mean that a unresizeable surface could still be tiled as long as both
the min and max size are set and set to the same thing. It wouldn't,
however, for aspect-ratio bound clients (neither would the capabilities
in this patch). We wouldn't be able to support that use case with this,
while the s/must/should/ would. Another alternative we could go with is
to add a 'can-be-force-resized' 'incapability' which would change the
requirements of the fullscreen/maximized/tiled_* states to
s/must/should/ only if that 'incapability' was set. We should probably
not call it 'incapability' or 'capability' if so though. Thoughts?

> 
> Nit: it should be <request> not <entry>. ;-)

Oops. I obviously haven't implemented it either, since I just threw it
together after our IRC discussion.


Jonas

> 
> Cheers,
> 
> > Jonas
> > 
> >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 23 +++++++++++++++++++++++
> >  1 file changed, 23 insertions(+)
> > 
> > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > index 563e39b..73944a8 100644
> > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > @@ -734,6 +734,29 @@
> >        </entry>
> >      </enum>
> > 
> > +    <enum name="capabilities">
> > +      <description summary="toplevel capabilities">
> > +	Certain xdg_toplevel states mandate certain client capabilities. For
> > +	example while a fullscreen:ed client is required to configure itself
> > +	according to the dimension in the configure event, some clients may not
> > +	have this ability due to various reasons.
> > +      </description>
> > +      <entry name="maximize" value="1"
> > +	     summary="the toplevel can be maximized"/>
> > +      <entry name="fullscreen" value="2"
> > +	     summary="the toplevel can be fullscreened"/>
> > +    </enum>
> > +
> > +    <entry name="set_capabilities">
> > +      <description summary="set capabilities">
> > +	Notify the compositor about what capabilities this xdg_toplevel
> > +	supports. This request can only be issued once and if so must be done
> > +	before the initial state is comitted. The default capabilities are no
> > +	capabilities.
> > +      </description>
> > +      <arg name="caps" type="array" summary="array of toplevel capabilities"/>
> > +    </entry>
> > +
> >      <request name="set_max_size">
> >        <description summary="set the maximum size">
> >  	Set a maximum size for the window.
> > 
> 
> 
> -- 
> 
> Quentin “Sardem FF7” Glidic