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

List:       kde-multimedia
Subject:    Re: PlayObject changes
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-07-19 9:57:52
[Download RAW message or body]

   Hi!

On Tue, Jul 18, 2000 at 09:46:55PM +0200, Martin Vogt wrote:
> >  > this should also seek back to the beginning, see below. If you use pause(),
> >  > the PlayObject will be PAUSED, and if you do play() again, it will be PLAYING
> 
> Hm. I have implemented a different bahaviour.
> after a halt() the PlayObject is reseted to the same default
> as after a new PlayObject().
> 
> This allows to do a loadMedia(file) after the halt.
>
> If you call play() after a halt this gives a segfault.
> (which is the same behaviour as after a new :-)

I don't see why you need the halt() here. If you *really* want to support
reloading media, why you don't simply can call play() pause() halt() as
usual, and if you call loadMedia() at any time, the PlayObject will stop
everything that is going on, and load the new media?

> The play() after a halt should be handled by the GUI, with
> 
> if(playObject.getState()==idle) {
>  playObject.loadMedia(currenfile);
>  playObject.play();
> }
> 
> btw: is this expected behaviout that the loadMedia method
>      is accessible in a playObject? The idl file put this
>      in PlayObject_private. I think it should be available.

I think that the PlayObject interface should only be about playing things,
not about loading them. The reason is simply that the way things are loaded
may be changed in KDE2.1 (like support loading from chained streams, like
http through gzip decompression or whatever), but the way things will be
played will remain untouched by this.

I.e. there may be PlayObjects which simply can't loadMedia(filename), since
they themselves are just accessing a GZipDecompressionStream (with a Stream
interface). So no, PlayObjects should be created by a factory, which in
turn knows which objects to plug together to achieve the desired effect.
Right now, things are still simple, but they will not always be.

So PlayObject should just do this one task, and this good. halt() and posIdle
was supposed to have a more 1:1 mapping of GUI to PlayObject functionality:

You offer the user the play, stop and pause buttons, and highlight play if
state is posPlaying, pause if state is posPaused and nothing otherwise.
If the user pushes play, you call play(), if he pushes pause, you call
pause(), and if he pushes stop, you call halt(). This should be easy to
understand for both, authors of PlayObjects and authors of players.

To the "may crash" issue: I don't think you should be able to crash anything
by calling public interface methods (remember you always take artsd down,
too). You usually also don't crash the X11 server by calling something in
the wrong order.

> >  > again. Well, I hope this is a logic choice of states now.
> >  > 
> see above.
> 
> 
> >  > 
> >  > Note: there was no stop before, because we said: well, you can always stop
> >  > it by using playObject = Arts::PlayObject::null(), which will cause its
> >  > reference count to drop and the PlayObject to go away. But for the user
> >  > interface it seems more convenient/logic to call halt() whenever the user
> >  > pushes the stop button, than terminating the PlayObject.
> >  > 
> 
> KJukebox will need the halt() behaviour and loadMedia to keep
> the overhead on startup and mixing as low as possible.
> 
> (see the test 3 in mpeglibartsplay)

See JEL mail. However, if KJukeBox really wants to do things like that anyway,
and there is no way we can get around this, we should perhaps do an interface

interface FileMedia {
	void loadMedia(string filename);
};

and get gid of the PlayObject_private interface altogether. Then the mpeglib
codecs could implement the FileMedia and PlayObject interfaces, and both,
the soundserver and KJukeBox could rely on it.

However, note that this also severly breaks if somebody has your mp3 codec,
but another mp4 codec, and you try to mix mp3 and mp4 files in the jukebox.

> >  > On the other hand, the PlayObject should know it's description (i.e. ID3
> >  > Tag), and setting this is not what you'll usually be able to do. Hmm, this
> >  > might be discussable, but I removed it for now, unless there are any strong
> >  > objections.
> 
> Yes, IMHO its not a good idea to put ID3 in the playobjects description.
> reason: we must discuss a format of the string.
> Should be handled by the GUI.

But the GUI will perhaps not even know about the file format it is right
now playing? The idea of PlayObjects is that in the GUI you don't bother
about file formats and things like that.

Description is just so that you can show the user something like "playing
Mozart - Kleine Nachtmusik" or so, without bothering too much.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         
_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia

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