Moving Sound into Core

[Evan Schoenberg]

On Jun 15, 2007, at 3:46 PM, Eric Polino wrote:

> I have been brewing over what to do about duplicating code.  As  
> Ethan pointed out, another layer of abstraction is pointless and/or  
> not needed.  Some have suggested to move sound into the core so  
> that UI's that want sound can hook into it, and those that don't  
> can just ignore it.  I'm not sure exactly how this would work as I  
> am new to a lot of this, but it seems to make sense to me at a  
> superficial level.  I'm starting up this thread to get a feel for  
> what people think about moving sound into the core.
>
> As it stands the sound that Finch has is pretty much a carbon copy  
> of gtksound with a few name changes here and there.
>
> Evan: Sean mentioned about that it would be good to ask  
> you...consider this asking you.

So presently, we have:
Libpurple sound.c: Allows the UI to register a function to be called  
to play a sound at a given path or to play a sound for a given event.  
For events, looks to some "while_status" preference which appears  
undocumented in this part of the code.  It appears that this  
preference determines whether sounds should play only when an account  
is available, whenever an account is online, or not at all.

Pidgin and Finch g?tsound.c:
1.  Registers for a variety of signals.
2. Responds to those signals by doing various checks specific to that  
signal, checking if the conversation has focus in the case of the gtk  
implementation and checking against a preference as to whether it  
should still make noise, and then passing the appropriate event to  
libpurple to play.

	(back in libpurple)
3. libpurple (sound.c) then calls back on g?sound.c to play the sound  
if and only if enough time has elapsed since the last invocation and  
no plugin tells it to stop.

I suppose (1) could possibly be in the core... except that then any  
UI is going to either need to accept the sounds provided by libpurple  
as a whole -or- utilize UI preferences or callbacks (which would need  
to be added) to disable certain ones.  Additionally, that's the  
minority of the code in question.  Most of it is in (2), from my  
quick look at it.  Moving (1) to being a libpurple plugin would just  
mean even more frustration for FutureUI Implementor; FutureUI would  
have to worry about whether the plugin is loaded if it's wanting to  
do different things with sounds, or just eschew the sound API  
altogether.

I don't see any advantages to moving this to the core or to a plugin.  
It's a UI problem.

-Evan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20070616/577ae0b1/attachment.html>