Where do we validate surface attributes?
alberto.aguirre at canonical.com
Wed Jul 1 18:45:27 UTC 2015
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
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...
More information about the Mir-devel