Phonon Five backend capabilities

[Casian Andrei]

2012/6/18 Harald Sitter <sitter at kde.org>:
> Since I was just talking about capability checks on IRC...
>
> In Phonon Five we should very much introduce some way of checking what
> a backend is able to do. Right now, frontend objects will simply do
> nothing if the backend cannot create an appropriate backend object,
> which is of course not transparent to the API consumer and therefore
> gets in the way of user experience. For example Amarok has a replay
> gain feature that does nothing with PVLC because it uses the
> volumefadereffect class. AudioDataOutput not being implemented for VLC
> 2 leads to an empty analyzer in Dragon.
>
> Now my immediate suggestion would be to have a simple
> QFlags(Phonon::Capabilities) Phonon::capabilities() function that
> returns ability of classes. This covers the better part of missing
> features as most of them will occur on a class level anyway [1].
> However in the long run that might not be sufficient...
> In particularly we were talking about the possibility of introducing a
> MediaObject::preload() function which addresses the use case of
> seek-before-play by constructing a pipeline and loading the media to
> the extent that one can seek and gets MediaData etc., but not
> generating any output until play() is called. Now libvlc does not
> support this, so if we were to introduce capability query support for
> this particular case it would have to be a Node capability rather than
> a Backend capability. A similar case already arises with the existing
> features. VideoWidget in PGST supports implicit surface rendering
> (i.e. if you put a PGST videowidget into a QGraphicsProxyWidget it
> will avoid xoverlay painting but instead use QPainter), it does right
> now not work with PVLC though. The API consumer will never know.
>
> So, unless someone strongly disagrees with backend level capability
> interface I guess my question is: does it seem worthwhile to have node
> level capability tracking or instead simply avoid cases where this
> would be necessary? By avoid I mean rather than make it a function,
> make it a node of its own (i.e. you'd have a Preload node that extents
> the MediaObject abilities much like MediaController does now) which I
> fear would, while more object oriented, actually lead to loads of
> silly classes.
>
> Alternatively one could simply have the backend capabilities enum
> include all of those corner cases as well (which is of course the last
> object oriented option but from a usage perspective it might not make
> much of a difference)  e.g.
> enum Foo {
>  ...
>  VideoWidgetCapability,
>  VideoWidgetSurfacePaintCapability,
>  ...
>  MediaObjectCapability,
>  MediaObjectReploadCapability
> }
> That is of course unless someone can actually think of a case where
> the capability would be runtime dependent in which case I would
> strongly dislike this option (we did a similar thing with the
> MediaController and that bites us mighty in the arm - designwise ...)
>
> Thoughts?
I fully agree with QFlags(Phonon::Capabilities), as it is simple and
effective for most of those capabilities.

In my opinion, extra node-level capabilities would be the most elegant
solution for those capabilities that don't fit with the backend. And
the consumer probably won't get too confused by them. The other
solution with new classes really looks like something that would bring
a lot of headaches.

Regards,
Casian