API

[Richard]

I agree. The best would probably be to query the backend for this  
using something like:

enum Feature{..};
bool MediaObject::featureAwailable(Feature f);

?

-Richard

On Jul 11, 2007, at 11:03 AM, Thierry Bastian wrote:

> Just one thought about "returning false if the backend can't handle  
> it".
> From a developer perspective this can seem reasonable but if we're  
> talking
> about applications it makes also sense to know in advance what are the
> features that are supported by the backend or not.
> Imagine you have a media player and a checkbox decides whether or  
> not you
> preroll, you would probably want to enable it only if the backend  
> supports
> this functionality.
>
> Thierry
>
> -----Original Message-----
> From: Richard [mailto:richardmg at trolltech.com]
> Sent: mardi 10 juillet 2007 15:20
> To: phonon-backends at kde.org
> Subject: Re: API
>
>
>> yes, but it's also connected to the source since you often want to
>> enable/disable preroll depending on what source it is, like e.g. a
>> radio
>> stream.
>> ...
>> Another one: when you stop a MediaObject will it preroll the
>> current source
>> again so that a subsequent call to play() is immediate?
>
> It sounds like there is no really clear answer to this, so it might
> be a good idea to let the user control it.
>
>> If you setCurrentSource(someRadioStream) and preroll starts and
>> then you wait
>> 5 min before calling play() what will you hear? 5min old stream?
>> current
>> stream? was the stream going over the network and getting dumped
>> to /dev/null
>> for the last 5 min then?
>
> I know QT uses preroll to acquire all neccesary resources up front,
> and set up needed connections. So even for radio preroll makes some
> sense there, at least. I would say preroll in the case of radio means
> start the streaming as if you were playing, but 'mute' it.
>
>> xinelib has no preroll concept so I have not really touched the
>> issue yet.
>
> cool. We could do e.g:
> bool MediaObject::setPreRollHint(bool preroll); // returns false if
> the backend can't handle it.
>
> -Richard
> _______________________________________________
> Phonon-backends mailing list
> Phonon-backends at kde.org
> https://mail.kde.org/mailman/listinfo/phonon-backends
>
> _______________________________________________
> Phonon-backends mailing list
> Phonon-backends at kde.org
> https://mail.kde.org/mailman/listinfo/phonon-backends



--
Richard Moe Gustavsen
Software Engineer II, Trolltech ASA
Sandakerveien 116, NO-0484 Oslo, Norway


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/phonon-backends/attachments/20070711/bb5e1995/attachment.html