Choosing a Phonon backend

[Ian Monroe]

On Thu, Mar 27, 2008 at 6:33 AM, Tanguy Krotoff <tkrotoff at gmail.com> wrote:
> On Wed, Mar 26, 2008 at 8:43 PM, Matthias Kretz <kretz at kde.org> wrote:
>  >  Yes, I'm considering adding something like a set of flags and then the
>  >  application can say
>  >
>  >  Phonon::setRequiredFeatures(Phonon::SomeFeature | Phonon::SomeOtherFeature);
>  >
>  >  The remaining problem is that there must be at least one backend for every
>  >  platform that supports all features otherwise the above call could result in
>  >  a situation where no backend would fit - which doesn't make sense.
>  >
>  >  And yeah, I don't think the application can be smarter than the framework in
>  >  deciding what backend to use. That's why there's no API to select the backend
>  >  from the API.
>
>  What about the user? can he be smarter than the framework to decide?
>  I'm developing a VLC + MPlayer backend.
>  So I imagine a video app that let's the user choose which backend he wants.
>
>  MPlayer does not handle DVD menus, VLC does. From the video app it
>  would be nice to say "for DVD playback I prefer the VLC backend and
>  for others videos I prefer MPlayer" or "for .mov files I prefer
>  MPlayer, for the rest VLC".
>  There will never be a backend "to rule them all" (ok, yes, Phonon will huhu)
>
>  Also from a developer point of vue, when I'm testing the VLC backend,
>  I have to remove all others backends (*.so/*.dll) from Qt directory
>  phonon_backend.
>
>  I don't know how to solve nicely/elegantly this problem. What I know
>  is that I don't want to see in a video app FAQ:
>  "to use the MPlayer backend, go to blabla phonon_backend, delete all
>  others backends *.so/*.dll/*.dylib"

On Windows especially it'd be nice to be able to distribute and then
use your own backend, since if I ever release Dragon Player on Windows
I would want to release it with phonon-vlc.

Ian