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

List:       alsaplayer-devel
Subject:    Re: [Alsaplayer-devel] Additions to the plugin interface
From:       Richard Boulton <richard () tartarus ! org>
Date:       1999-10-01 15:53:22
[Download RAW message or body]

On Thu, Sep 30, 1999 at 12:55:13PM +0200, Andy Lo A Foe wrote:
> flags can be used to communite capabilities of this plugin to alsaplayer.
> Right now no flags are defined and thus checked. Suggestions for flags are
> welcome. Things like INPUT_CAN_REVERSEPLAY, INPUT_CAN_SEEK,
INPUT_CAN_SEEK is a good one - I've been thinking we could do with that
for a while.  INPUT_CAN_REVERSEPLAY would be implied by INPUT_CAN_SEEK
though, wouldn't it?

Actually, I'd suggest doing INPUT_CAN_SEEK by setting the frame_seek
field to NULL if we can't seek - that removes all risk of the
implementation and the flags being out of sync.  But I'm sure the
flags will be useful for something else.

> INPUT_NEED_SMALL_BUF, etc. etc.
Not sure what you'd want that for?

> input_cleanup_type cleanup;
> 
> this is an optional cleanup function that prepares the plugin for removal
> (frees allocated memory,e tc)

Right, good, brings us closer to being able to change loaded plugins
around while the program is running...

> Gone is also the hardcoded base version value, and the maximum plugin
> count. These are now #define'd. The plugin version was also bumped up.
This is a bit better, but I dislike limits, in principle.  *grins*
Is there any reason that the STL isn't used anywhere in alsaplayer so far?
We could store the plugins in a <vector>, which would dynamically
size.  Various other places the code could be made far nicer as a result,
too.

I've actually been using STL stuff in the new playlist stuff, so
if there _is_ an insurmountable problem, tell me quick.  I think
STL implementations are pretty good and available these days, aren't
they?

Other things:  I've updated the CVS with v0.99.28pre3, and done the
moving of files around. (I havn't removed the old versions
(app/{input,output,scopes}) yet, but will do soon, and they're
ignored by everything now.)

Am about to do some more work on the Playlist stuff, should be working
properly soon.  I'd suggest that you move to the CVS properly now -
it seems like a waste of some of our effort not to.

The basic way the playlist stuff will work is as follows:

There's a Playlist class, which has nothing to do with the GUI, and has
append, clear, insert, next, prev, etc. functions.  There's also a
PlaylistInterface class which is virtual and defines a set of callbacks.

A real Playlist Window class, (currently there's only PlaylistWindowGTK)
inherits this interface, and registers itself with the playlist.
Then, whenever the Playlist changes, it calls the appropriate callback
for all registered PlaylistInterfaces so that they can keep themselves
up to date.

I'll try and explain more clearly in docs at some point soon.

--Richard



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