Discussion about Zinf audio player development

Tim Lesher | 1 May 14:18

Re: being serious about the NG of zinf

On Wed, Apr 30, 2003 at 09:01:24PM -0400, Ed Sweetman wrote:
> Right now I'm opposed to using threads for the main player.

That's a good start.  There's rarely a problem that can be solved with
threads that can't be solved more simply and reliably with other
means.

While the pipeline probably doesn't need to be threaded, we might want
to allow the UI to exist on another thread, and then put all the
UI/pipeline interactions in a very tight interface.

> In other areas of design, ideas such as the mapped strings for managing 
> preferences are going to be put into use.  [...]

Great.  I was thinking about something very similar.  The preferences
coupling should be as loose as possible.

> changing in the meantime, we need a boolean member to info called lock. 

Checking a variable doesn't prevent race conditions at all because
threads can be switched after checking the condition, but before
reading the data.

We'll either need to use a real synchronization object, or else
stipulate that plugins can only read the info object from the main
(creation) thread.

> I do 
> still have my doubts on how feasible it will be to not depend on libs 
> for certain protocols in the input plugins so this is still

(Continue reading)

headers

Ed Sweetman | 1 May 19:37

Re: being serious about the NG of zinf

Tim Lesher wrote:
> On Wed, Apr 30, 2003 at 09:01:24PM -0400, Ed Sweetman wrote:
> 
>>Right now I'm opposed to using threads for the main player.
> 
> 
> That's a good start.  There's rarely a problem that can be solved with
> threads that can't be solved more simply and reliably with other
> means.
> 
> While the pipeline probably doesn't need to be threaded, we might want
> to allow the UI to exist on another thread, and then put all the
> UI/pipeline interactions in a very tight interface.
> 
> 
>>In other areas of design, ideas such as the mapped strings for managing 
>>preferences are going to be put into use.  [...]
> 
> 
> Great.  I was thinking about something very similar.  The preferences
> coupling should be as loose as possible.

preferences and the playlist are just mapped strings.  plain and simple. 
  Of course like the preferences, the player isn't going to talk to the 
mapped string directly.  The preferences are wrapped in the info class 
and accessed by methods in it.  The playlist will be accessed by a 
playlist class that gives complete functionality that you've come to 
expect from the gtk ui and more.  I'd like to offload functionality from 
the UI's and allow the ui subsystem to be just that, the user interface 
and not part of the "program."

(Continue reading)