Where do we validate surface attributes?

Daniel van Vugt daniel.van.vugt at canonical.com
Thu Jul 2 01:58:18 UTC 2015


I agree with Alberto et al here.

Anything other than range and syntax checking in libmirclient is too 
much. Semantic checks must be done on the server because the definition 
of what is semantically correct varies between shells. An app should be 
written once, try to set everything it wants, send the request off and 
see if the server (shell) accepts it. To do semantic checking in 
libmirclient limits the number of shells your app will ever be able to 
run in.

In fact I don't think it's even a matter of failure -- I would like to 
see shells just always do a best effort and never fail to start an app. 
That's more like how X window managers work today. Your app won't fail 
to start, but it may not look best under all WMs. There, surface types 
and states are more of a hint than a rule. And IMHO that X approach is 
better because at least your app always starts. If it doesn't start then 
you may be stranded, unable to fix the app to run on your shiny new shell.


On 02/07/15 02:45, Alberto Aguirre wrote:
>
> On Tue, Jun 30, 2015 at 11:35 PM, Christopher James Halse Rogers
> <chris at cooperteam.net <mailto:chris at cooperteam.net>> wrote:
>
>     On Wed, Jul 1, 2015 at 3:36 AM, Alberto Aguirre
>     <alberto.aguirre at canonical.com
>     <mailto:alberto.aguirre at canonical.com>> wrote:
>
>         I think we should avoid replicating validation rules when
>         possible, because in the end, validation is really up to the
>         window manager policy - its the one entity which knows the valid
>         combination of parameters.
>
>
>     I don't think this should be true, and it certainly *wasn't* true
>     when we had a constrained client API.
>
> I guess I disagree. We have a core policy object that shells should
> reuse, in which we can just centralize the validation of parameters.
>
>
>     There are certainly *some* attributes that are going to be
>     shell-specific - window sizes, fullscreen placement, and so on - but
>     I think there's a core that aren't. It doesn't make sense to make a
>     menu surface without a parent, and so on.
>
>
> Yes, but I still think that core lives in the window manager policy that
> we already have in mir, which shells should use.
>
>
>     Our client API isn't usable if we don't have defined semantics for
>     various things - how does input interact with having a menu open?
>     What happens if you make a menu with a menu as a parent? What
>     happens if you close a menu?
>
>     For the benefit of both clients and shells it would be good if we
>     implemented at least some of this in Mir. A correct shell will need
>     to have this behaviour, and clients will need to be able to depend
>     on this behaviour.
>
>
> We do, that's the core window management policy that shells should use
> (and indeed qtmir will use).
>
>
>     The semantic content of our API is not just there so that shells can
>     do the right thing when a client creates a parented-dialog; it's
>     also there so that clients can know what the right thing is.
>
> Agreed, however, only up to a certain set of shell types (i.e. unity/gtk
> like, 2D windowing thingies).  A completely different shell (say a VR
> shell) may have completely different client semantics anyway - the
> question is do we want to support such things?
>
>
>



More information about the Mir-devel mailing list