[PATCH] KPlayObject fixes for asynchronous generation + patch for kaboodle

Matthias Welwarsky matze at stud.fbi.fh-darmstadt.de
Sun Sep 1 11:40:31 BST 2002


On Sunday 01 September 2002 00:11, Neil Stevens wrote:
> On Saturday August 31, 2002 02:50, Matthias Welwarsky wrote:
> > Streams are
> > not seekable anyway so this is not really a problem.
>
> 1.  The PlayObject needs to avoid returning seekable for non-seekable
> streams, then.

This is already the case. The proxy object just returns "zero" capabilities.

> 2.  This patch applies to KPlayObject, which is used for more than just
> non-seekable streams.  If you want apps to assume that this PlayObject is
> a stream, then you should make a new KStreamingPlayObject.  For without
> the capability returning the correct value, apps can't just guess on this!

The app can just call KPlayObject::stream() to know if it's a stream or not. 
KPlayObjects are not meant to be created directly by an application anyway, 
only through the factory, so there's no reason for a KStreamingPlayObject.

> > Pausable is admittedly a problem, though I'd not call
> > it a "major regression". Just be sure not to cache the capabilities.
>
> Well, as long as I will reasonably quickly get the signal, I can just
> assume non-pausable, then enable pausing once the signal arrives and the
> capabilities include pausable.

You cannot predict when you will get the signal, because this depends on how 
long it takes to make the connection to the data source. It can be a fraction 
of a second, or 10 seconds, or a minute. So, I think the best way is to 
disable all actions but "play", and to enable them once the signal arrives, 
depending on the capabilities returned.

Meanwhile, I've done some further enhancements, inspired by Simon Hausmann, 
who suggested that the KPlayObject should behave sensible on calls to "play" 
and "pause" or "halt" even while only the proxy object exists. KPlayObject 
now maintains an internal state that is updated according to "play", "pause" 
and "halt". This state is returned by the proxy object instead of 
Arts::posIdle.

This also means you can safely call "play" and then "pause" while the 
connection to the data source is still being made, and it will not start to 
play once the connection is established.

regards,
	matze

-- 
Matthias Welwarsky
Fachschaft Informatik FH Darmstadt
Email: matze at stud.fbi.fh-darmstadt.de

"all software sucks equally, but some software is more equal"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-multimedia/attachments/20020901/9266a545/attachment.sig>


More information about the kde-multimedia mailing list