mir's internal renderer + other shells

[Daniel d'Andrada]

On 28/03/14 17:47, Mirco Müller wrote:
> Am 28.03.2014 20:48, schrieb Kevin DuBois:
>> ...
>> Given this, what I would want is mir to handle all the junk about
>> clients, ipc, buffer swapping, etc. I'd just want to write GL; my own
>> shaders, my own algorithms, my own GL state. [3] I wouldn't really be
>> interested in using mir's GL stuff (triangle tesselation? bah! I want
>> to write zany jigsaw tessellations and name the vertex attrib what I
>> want to name it!)
>> ...
>      This is pretty much what I would like to encounter, when I'd
> consider diving into writing my own shell. Free me from all the boring
> stuff and give me all the freedom to go wild with GL.
>
>      Maybe only input could be bit more pre-digested with the option to
> also get raw events unprocessed. So by default getting... let's pick an
> example... "pinch"-events instead of each single tap and related movements.
>
> Best regards...
>
> Mirco
>

I would be careful with that wish list. Before long we can find 
ourselves with a Mir toolkit and I don't think we should be writing 
another nux.
It's pretty clear that any minimally complex/sophisticated shell 
implementation will have to leverage a toolkit to get the job done. You 
simply cannot go very far with pure GL and raw events (you would likely 
end up writing your own micro-toolkit inside your shell code when trying 
to go that way).
I think shell should just get pure GL and raw input events and then the 
implementor can decide which toolkit he is going to plug on top of that: 
be it Qt, clutter, some 3d game engine, the sky is the limit.

Ah, as for the pinch: Qt has PinchArea, clutter has ClutterZoomAction...