Hello everybody.<br>As some of you may already know I'm currently trying to guide the Plasma Media Center project and I'm quite happy with the results we are achieving.<br><br>The project is still highly work in progress and therefore we have issues here and there i'd like to point out in this mail.<br>
<br>The first *big* issue we have is Phonon; and this is a relevant one since our business are Media resources.<br>Phonon::VideoWidget inside a QGW sucks great and currently we also have that white-skin people are rendered blue (yeah, like Avatar).<br>
I already mentioned the aim is to show the video full screen and having it embedded inside a QGW is way ugly as it is rendered badly.<br>I did some investigation and found out that probably QtMultimedia will help us fix this.<br>
Unfortunately QtMultimedia won't be shipped until Qt 4.8 and so a decision in this direction has to be taken.<br>At the very beginning we had the idea to put a plain VideoWidget behind the transparent-made containment (really, the Plasma::View)<br>
but IIRC this is not possible as long as there is a window registered as desktop in the WM.<br>The second idea was to continuously ask the VideoWidget for snapshot()s and directly paint them over the QGW.<br>I tried this but it is really really bad performing.<br>
One more test was done trying to redirect the painting, specifically doing it with grabWidget. But this seems not to be possible<br>as the Phonon::VideoWidget is not a pure QWidget. grabWindow is not possible as the window should be hidden.<br>
Please correct me if I'm wrong and point out some advice.<br>Also, no way i should try to already make use of QtMultimedia in place of Phonon for the QGraphics* stuff?<br><br>The second aim we have is to allow different kind of inputs to be used for the Media Center interaction.<br>
Me and Sebas were investigating wiimote capabilities and later Sebas pointed out this project [0].<br>It seems to me really well done with a good level of abstraction for the wii controllers.<br>I already contacted the author in order to have more info about that but unfortunately he still didn't reply.<br>
My concern about this regards how making the input handling enough "general" to be extended via wiimote plugins and stuff like that.<br>For example, currently the browsing applet handles keyEvents in order to move the selection indicator.<br>
How should I handle such events in order to allow further extension via other kind of input devices? Any hint for me?<br><br>I'd like such points to be discussed before we reach akademy so that I'll introduce our approaches in such aspects.<br>
<br>Thank you for your time.<br><br>P.S.: Also, shall I CC some other ML that might be interested in this? If so, can you suggest which ones?<br><br>[0] <a href="http://gitorious.org/wiimotedev">http://gitorious.org/wiimotedev</a><br clear="all">
<br>-- <br>Alessandro Diaferia<br>KDE Developer<br>KDE e.V. member<br>
<br>