[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Phonon Five backend capabilities
From:       Harald Sitter <sitter () kde ! org>
Date:       2012-06-18 0:23:37
Message-ID: CAEc+18HYBEMrm-oXK_zZCydqsrxj40tJnJeeVganibVshm81LQ () mail ! gmail ! com
[Download RAW message or body]

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?

[1] http://community.kde.org/Phonon/FeatureMatrix

HS
_______________________________________________
kde-multimedia mailing list
kde-multimedia@kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia
[prev in list] [next in list] [prev in thread] [next in thread]