Heya,
For Phonon5 it looks like the "Source" class needs a complete rewrite, as Harald pointed out to me on IRC.
Here is a quick draft API proposal for this:
=== Source needs to handle:
* Local file, URL, stream
* Audio CD, DVD:
- set track
* Video CD, DVD:
- navigate menus
- chapters, titles
- subtitle config
- audio channels
* Hardware devices:
- set audio/video device
- device settings
=== Classes:
* GenericSource (set URL) - local files, URLs, streams
* AudioDisc (set track)
* VideoDisc (menus, chapters, titles, subtitles, audio channels)
* MediaDevice (set video device, set audio device, configure device)
=== API sketch:
The thinking is that these multimedia sources like dvd's, hardware devices, etc. don't remove or drastically change features so the API shouldn't need to change. I'm not sure how this inheritance works with the frontend/backend system though...
* Source (namespace? or static functions in GenericSource?) (convenience functions)
- GenericSource * Source::create(QUrl) (detects source type, creates proper source class)
- bool Source::isAudioDisc(GenericSource *) (dumb cast, gives impression of friendliness)
- bool Source::isVideoDisc(GenericSource *) (same dumb cast)
- bool Source::isMediaDevice(GenericSource *) (same dumb cast)
* GenericSource
- bool isValid()
- get/setUrl(QUrl)
a. local file: "file:///home/user/foo.avi"
b. some url: "
http://foosite.tk/?w=abcd0000"
c. stream: "mms://
barsite.tk:1234"
d. "file:///dev/video0" (url for video device?)
e. "file:///dev/cd" (url for disc?)
* The backends might be able to provide info about what kind of source is for a URL
This is how I would like it to be, but... Now I'm not sure if this has critical flaws or weaknesses. Is it an acceptable solution? Can it be implemented? Do you like this kind of API?