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 _______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
