Moving Sound into Core
evands at pidgin.im
Sat Jun 16 18:15:34 EDT 2007
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
I don't see any advantages to moving this to the core or to a plugin.
It's a UI problem.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel