phonon5 and times

[Harald Sitter]

More API fun ahead!

in phonon4 we had the following time properties:
- tick (played milliseconds changed)
- tickInterval (how often one is informed about a tick)
- totalTime (total amount of milliseconds to be played)
- remainingTime (totalTime - tick)

the latter two are fine the former two I don't find too amanzing

== tick ==
while tick sounds very fancy I don't think it does anything for
discoverability here. for Phonon5 I'd like to change it to
qreal time() const;
Q_SIGNAL void timeChanged(qreal time);

==tickinterval==
additionally the interval thing seems a bit copious to deal with. I
have yet to see someone set interval to something other than a random
fixed value like 50msc. MS suggested a spatial tick at some point
(i.e. calculate ticking such that you'd get fluent progressbar/slider
movement) but IMHO that had better been implemented in each
application so one has better control over the madness.
so, where am I going with this?
the reason the interval is there is because updating the gui 30000
times a second makes no sense and usually a tick will cause gui thread
wakeups/events (be it only to check whether to actually emit a tick
signal).
for phonon5 we can:
a) keep it and rename it to timeUpdateInterval (to align with rename of tick)
b) drop the interval; always use >=100 msc updates
c) drop the interval; always use ~100 msc (if VLC is ticking faster
than that we go <100)
d) any of b) or c) AND when nothing is connected to timeChanged() no
ticks will be generated in general == no resources consumption
(QObject::connectNotify) AND time() does not access cached values but
will lead to a direct pipeline query

personally I would go with b+d) as to me those make most sense. by
default there's a sensible update interval that is not too resource
consuming. if one wants more precise time values then you'd simply not
use the builtin timeChanged but use your own QTimer to query time().
which actually is superior to what we had before because it actually
encourages avoiding a lot of our abstraction overhead when one wants
accurate values (calling time() will result in a direct access on the
pipeline, timeChanged() is a queued and therefore eventloop bound).

thoughts? opinions?

HS