<div dir="ltr"><div class="gmail_default">My understanding, after discussion during standup, is that the validation of attributes should be left to the WM policy. Mir will have a default one, but shells can override it if they so choose. Though this approach has some shortcomings.</div><div class="gmail_default"><br></div><div class="gmail_default">Of course, a shell can only diverge so much from the default policy. E.g. implementing a VR shell without changing the client side semantics would not be possible. So a new shell would still have to be bound by the existing notions of what a Dialog, or a tooltip is. But within reasonable limits, some tweaks to behavior can be made (everything fullscreen, etc).</div><div class="gmail_default"><br></div><div class="gmail_default">Invalid combinations of attributes will generate errors and logged so clients can figure out what they are doing wrong.</div><div class="gmail_default"><br></div><div class="gmail_default">A problem I see is that this would require clients to be aware of which shell they are running on so they generate attribute settings that conform to that particular shell. That doesn't sounds like a good thing. An application running perfectly on a particular shell may start getting errors on a new shell. Not sure what we can do there. Anybody have ideas?</div><div class="gmail_default"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 30, 2015 at 1:39 AM,  <span dir="ltr"><<a href="mailto:raof@ubuntu.com" target="_blank">raof@ubuntu.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey all,<br>
<br>
In response to Alan's comment¹ and my follow-up² I'd like to bring up a design question: do we validate surface states before handing them off to the shell, and if so, where?<br>
<br>
Previously we ensured that client couldn't create invalid surfaces - a menu without a parent, a normal surface with a parent, etc - by making impossible to express such surfaces through the client API.<br>
<br>
We've abandoned that approach, as it was starting to impose significant costs for not a huge gain, and now clients can create whatever MirSurfaceSpec they desire.<br>
<br>
I think we should still do that validation before handing off to the shell. My understanding is that AbstractShell::WindowManager is expected to be Shell code, so this would be a filter between FrontendShell and AbstractShell?<br>
<br>
What do others think? Do we want to do the validation at all, or should we punt it to the shell?<br>
<br>
¹: <a href="https://code.launchpad.net/~raof/mir/input-methods-can-specify-foreign-parents/+merge/258001/comments/656064" rel="noreferrer" target="_blank">https://code.launchpad.net/~raof/mir/input-methods-can-specify-foreign-parents/+merge/258001/comments/656064</a><br>
²: <a href="https://code.launchpad.net/~raof/mir/input-methods-can-specify-foreign-parents/+merge/258001/comments/658830" rel="noreferrer" target="_blank">https://code.launchpad.net/~raof/mir/input-methods-can-specify-foreign-parents/+merge/258001/comments/658830</a><span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
-- <br>
Mir-devel mailing list<br>
<a href="mailto:Mir-devel@lists.ubuntu.com" target="_blank">Mir-devel@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/mir-devel" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/mir-devel</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Cemil Azizoglu<div>Mir Display Server - Team Lead</div><div>Canonical USA</div></div></div>
</div>