Choosing a Phonon backend

[Tanguy Krotoff]

Nice thread :p

My app is specific and needs specials features that the default
backend is not designed for.
Say my app does not simply use Phonon::playSound()

What I want to do is:

* Choose MY app Phonon backend

Because otherwise my very specific app is almost USELESS for my users.
For example DS9 backend under Windows is useless for a video player
because it does not integrate codecs as VLC or MPlayer does. I guess
it is the same under MacOSX.
In the future it will be for another good reason (BlueRay...), who knows?
For an app that does only use Phonon::playSound() yes it is definitely enough.

What is the cost of providing
bool Phonon::setBackendName()
with a huge warning "don't call this function if you don't know what
you are doing"?


* Access to some specials features from a specific Phonon backend

Even if it's dirty. It's MY app, it does not affect others apps.
I can need to access these features for various reasons: debugging,
testing, very specific features needed by my app, very interesting
innovations from a backend...
And maybe if the "specials features" are interesting/needed by other
apps, then integrate them into a nice Phonon API extension.
Otherwise, how do you test new features that will come overtime and
integrate it into Phonon API?
I hope that Phonon API will involve and improve in the future, reflect
improvements from the multimedia area. How do you think Phonon will
address innovations that will come? Who knows what innovation will
come next? Is it that hard to my Phonon flexible? is it against who
knows philosophy?

What is the cost of providing:
QObject * Phonon::getInternalBackend()
again with a huge warning "don't call this function if you don't know
what you are doing"?

Even if I know that MY code will be difficult to maintain and is
dirty; I need it, otherwise I don't even get the features my users
need. I don't do this "just for pleasure"!
Others devs that only use Phonon::playSound() don't care that MY code
can be dirty!


What is the point for me coding VLC/MPlayer backends on my spare time,
get my girl screaming after me being behind my screen... if I cannot
even choose the VLC backend or access advanced subtitles features from
MPlayer for my advanced video player?


* Example

SMPlayer is a nice piece of software http://smplayer.sourceforge.net/
Developed in Qt4 and multiplatform. By many ways it surpasses VLC GUI.
Ricardo Villalba spends a lot of time developing this app, and I thank him.

Problem is that SMPlayer is dependent from MPlayer process.
So I proposed him to create a VLC and a MPlayer Phonon backend and
then integrate it into SMPlayer.
Then he gets a clean separation from the backend and the GUI via a
very nice API: Phonon + possible to choose another backend + others
apps like Dragon Player can use VLC/MPlayer Phonon backends
He is helping me by providing a libsmplayer that will be the base of a
MPlayer backend.
But he might want also to test and provide specials features from MPlayer.
He might also improve Phonon as innovations are going on.

Dragon Player experience also proved that it is sometimes necessary to
access the internal backend
cf
http://lists.kde.org/?l=kde-multimedia&m=120663960520654&w=2

Can we remove the lock and let innovation go as it should?

-- 
Tanguy Krotoff <tkrotoff at gmail.com>
+33 6 68 42 70 24