These are mir demos that excercise private in-flux mir functionality.
As such functionality matures, related headers become public and the playground
code may become an example of how to use such feature.
The reason for this MP is to drive a discussion of what is preventing users of our supported API doing what we do in the mir_demo_server_shell example.
As I see it the only real problem highlighted by this MP is that the DemoRenderer class that has been implemented using some of our private gl tools. That is I don't see that access to the_compositor_report() or the_input_scene() is a big deal.
So the question is: how do we serve our current and potential users better?
1. Provide an example of shell decorations etc that doesn't use Mir internals
2. Design a way for users to implement shell decorations that we're happy to publish
3. Ignore the issue
Using our private gl tools isn't the only implementation option and (as Kevin says) our existing downstreams haven't found a need for this approach. It would be good to have an example that is more like what we expect users to do.
Quoting the README:
The Playground
These are mir demos that excercise private in-flux mir functionality.
As such functionality matures, related headers become public and the playground
code may become an example of how to use such feature.
The reason for this MP is to drive a discussion of what is preventing users of our supported API doing what we do in the mir_demo_ server_ shell example.
As I see it the only real problem highlighted by this MP is that the DemoRenderer class that has been implemented using some of our private gl tools. That is I don't see that access to the_compositor_ report( ) or the_input_scene() is a big deal.
So the question is: how do we serve our current and potential users better?
1. Provide an example of shell decorations etc that doesn't use Mir internals
2. Design a way for users to implement shell decorations that we're happy to publish
3. Ignore the issue
Using our private gl tools isn't the only implementation option and (as Kevin says) our existing downstreams haven't found a need for this approach. It would be good to have an example that is more like what we expect users to do.