<div dir="ltr">Definitely not suggesting it's not useful, or that we should remove it. But "playground" (I am not a big fan of the name either) has one specific purpose stated previously but now includes code that doesn't contribute to that purpose (again, it does contribute to other just as useful purposes).<div><br></div><div>What I'm suggesting is we should migrate to public whatever we think should be public, so you got solid support for that code. The rest should move elsewhere (perhaps "internal examples" as opposed to "examples" which I'd consider external)  and even perhaps off the tree.</div><div><br></div><div>Regards,</div><div>Cemil</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 2, 2015 at 2:50 AM, Thomas Voß <span dir="ltr"><<a href="mailto:thomas.voss@canonical.com" target="_blank">thomas.voss@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Apr 2, 2015 at 4:36 AM, Daniel van Vugt <span dir="ltr"><<a href="mailto:daniel.van.vugt@canonical.com" target="_blank">daniel.van.vugt@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All the features are useful. And use of the word "playground" was not my choice (I was outvoted). They have all been used to develop other features or to diagnose bugs in Mir, or soon will be used when I find the time. By function you can see them documented here:<br>
<a href="http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/doc/demo_shell_controls.md" target="_blank">http://bazaar.launchpad.net/~<u></u>mir-team/mir/development-<u></u>branch/view/head:/doc/demo_<u></u>shell_controls.md</a><br>
<br>
The "cosmetic" stuff is also very useful. Shadows for example make the stacking order obvious. Title bars show you that you have the correct title string and that the new API for that works. Which I needed just recently. The zoom feature I've used repeatedly to see fine pixel details and even yesterday as an aid in measuring latency.<br>
<br>
I use mir_proving_server every day. It helps me to find bugs that no one else on the team is noticing (but should). Management has asked me on a couple of occasions "what is your trick to finding bugs that nobody else does?". The answer is daily manual testing with mir_proving_server.<br>
<br>
It's also worth noting that one of Cemil's first contributions (seamless rotation) would not have been possible without mir_proving_server. And Gerry uses mir_proving_server regularly to compare features. Including yesterday, he used it to test resizing, which is more feature complete in mir_proving_server than elsewhere.<br>
<br>
Most importantly however, something slightly pretty motivates people to get involved. Either directly in Mir or downstream, it allows them to see potential for Mir which is impossible for most people to see in flat rectangles. Sparking peoples' imagination is invaluable.<br>
<br>
Something like this that people use every day should not be deleted. That would be most unhelpful. But mold it into some slightly different form, sure.<span><br>
<br></span></blockquote><div><br></div></span><div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif">​I'm not sure where your reservation arises from, but no one proposes to delete useful code. On the contrary, people appreciate the usefulness of the code and propose to graduate it to the production base such that it is under test and guaranteed to be working.​</div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif"><br></div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif">Thanks,</div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif"><br></div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif">  Thomas</div><br></div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<br>
On 02/04/15 00:03, Alberto Aguirre wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
Once we release mir 0.13 we can tell our colleagues to use<br>
mir_demo_server instead.<br>
<br>
 From what I can see, features missing from the demo server in<br>
comparison to proving server are mostly cosmetic. If they are not, can<br>
Daniel list the features that are missing?<br>
<br>
<br>
<br>
On Tue, Mar 31, 2015 at 8:40 PM, Daniel van Vugt<br></span>
<<a href="mailto:daniel.van.vugt@canonical.com" target="_blank">daniel.van.vugt@canonical.com</a> <mailto:<a href="mailto:daniel.van.vugt@canonical.com" target="_blank">daniel.van.vugt@<u></u>canonical.com</a>>><div><div><br>
wrote:<br>
<br>
    Last I checked mir_proving_server was more functional and less buggy<br>
    than our other example servers. That and our colleagues tend to use<br>
    it as their primary development platform when testing toolkit/app<br>
    ports. So mir_proving_server is important and should be reworked to<br>
    use any newer APIs you would prefer it to use.<br>
<br>
    I know it's frustrating the number of regressions we've had this<br>
    past week or so. But to blame the functionality that regressed more<br>
    than the person who regressed it I think is disproportionate.<br>
<br>
    Yeah that "god" function is annoying. It needs to be teased apart. I<br>
    can help with that but it's not a major priority right now.<br>
<br>
    Please try to avoid belittling the project by using words like<br>
    "playground" and "dark corner". It's important and useful example<br>
    code that myself and others use every day to do our jobs. So if you<br>
    want it modernised, let's do it.<br>
<br>
<br>
<br>
    On 31/03/15 21:12, Alan Griffiths wrote:<br>
<br>
        There's a bunch of code in the mir project that isn't needed for<br>
        supporting the public interfaces (neither by implementing them,<br>
        testing<br>
        them nor demonstrating their use). This code lies in<br>
        "playground" and<br>
        shares that location with the following README:<br>
<br>
             The Playground<br>
<br>
             These are mir demos that excercise private in-flux mir<br>
        functionality.<br>
             As such functionality matures, related headers become<br>
        public and the<br>
             playground<br>
             code may become an example of how to use such feature.<br>
<br>
        It has now been some time since any functionality has "matured" from<br>
        playground and become public (either as APIs or examples). I<br>
        don't see<br>
        any evidence that the code there is being developed toward such<br>
        an event<br>
        in the foreseeable future.<br>
<br>
        The requirement to support this code is becoming a burden as it<br>
        makes<br>
        use of internal APIs in a way that limits the evolution of Mir<br>
        internals. Updating the code is also costly as it has grown in an<br>
        uncontrolled manner (most of the logic seems to be in one 223<br>
        line "god"<br>
        function). Because it not under test to the same extent as Mir<br>
        production code we've had a number of breakages to this code land on<br>
        trunk recently (often to features I wasn't previously aware of).<br>
<br>
        So the questions:<br>
<br>
        1. Does "playground" still provide a proving ground for new code to<br>
        germinate? Or is it dark corner for legacy code to go and die?<br>
        2. Do we still need a proving ground like this? Or do our public<br>
        APIs<br>
        now support enough functionality to drive feature development?<br>
        3. If we still need a proving ground is it desirable to rework<br>
        this code<br>
        to be better aligned with the rest of the project?<br>
        4. If we don't need "playground" is there anything we need to<br>
        provide<br>
        before dropping it from the project.<br>
<br>
<br>
<br>
    --<br>
    Mircosmonauts mailing list<br></div></div>
    Mircosmonauts@lists.canonical.<u></u>__com<br>
    <mailto:<a href="mailto:Mircosmonauts@lists.canonical.com" target="_blank">Mircosmonauts@lists.<u></u>canonical.com</a>><span><br>
    Modify settings or unsubscribe at:<br></span>
    <a href="https://lists.canonical.com/__mailman/listinfo/mircosmonauts" target="_blank">https://lists.canonical.com/__<u></u>mailman/listinfo/mircosmonauts</a><br>
    <<a href="https://lists.canonical.com/mailman/listinfo/mircosmonauts" target="_blank">https://lists.canonical.com/<u></u>mailman/listinfo/mircosmonauts</a><u></u>><br>
<br>
<br>
</blockquote><div><div>
<br>
-- <br>
Mircosmonauts mailing list<br>
<a href="mailto:Mircosmonauts@lists.canonical.com" target="_blank">Mircosmonauts@lists.canonical.<u></u>com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.canonical.com/mailman/listinfo/mircosmonauts" target="_blank">https://lists.canonical.com/<u></u>mailman/listinfo/mircosmonauts</a><br>
</div></div></blockquote></div></div></div><br></div></div>
<br>--<br>
Mircosmonauts mailing list<br>
<a href="mailto:Mircosmonauts@lists.canonical.com">Mircosmonauts@lists.canonical.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.canonical.com/mailman/listinfo/mircosmonauts" target="_blank">https://lists.canonical.com/mailman/listinfo/mircosmonauts</a><br>
<br></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>