Where do we validate surface attributes?

[Alberto Aguirre]

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).

>
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20150701/5b1b67ec/attachment.html>