Where do we validate surface attributes?

Christopher James Halse Rogers chris at cooperteam.net
Thu Jul 2 05:18:29 UTC 2015



On Thu, Jul 2, 2015 at 4:45 AM, Alberto Aguirre 
<alberto.aguirre at canonical.com> wrote:
> 
> On Tue, Jun 30, 2015 at 11:35 PM, Christopher James Halse Rogers 
> <chris at cooperteam.net> wrote:
>> On Wed, Jul 1, 2015 at 3:36 AM, Alberto Aguirre 
>> <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).

I guess this is what I'm getting at: we've got a component that we 
expect shells to use, and that shells which *don't* use it will need to 
reimplement or break our client API. Why would we let a shell override 
this in the first place?

Hm. Maybe we're actually agreeing? We'll have this validation layer in 
the core WM code, before the code that we expect shells to override?

>> 
>> 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?

We can't. Or, rather, supporting them requires new client API anyway. 
If they have different semantics then they have a different API, even 
if that API uses functions with the same name.

The client API isn't just the set of C-linkage entrypoints. The 
semantics are a part of the API.




More information about the Mir-devel mailing list