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