On Tue, Jun 30, 2015 at 11:35 PM, Christopher James Halse Rogers < ch...@cooperteam.net> wrote:
> On Wed, Jul 1, 2015 at 3:36 AM, Alberto Aguirre < > alberto.agui...@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?
-- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
