Alright, I guess we better go with the UI approach.
On Tue, 13 Sep 2005 12:17:57 -0400, Evan Schoenberg wrote
> I think that gaim_sound_play_event() should be a UI, not a core,
> If a UI wants to play sounds when a particular event occurs, it can
> call its own play functions within that event's callbacks, after
> doing whatever determination it wants to do for "should this sound
> play," "what sound should play," etc. Sound is inherently a user
> interface thing; libgaim should simply be notifying the UI of events
> (contact status changed, account connected, etc.).
> On Sep 12, 2005, at 8:48 PM, Casey Harkins wrote:
> > After discussing this issue with kingant and lschiere on #gaim,
> > they suggested moving the discussion here to get others opinions.
> > The basic question is: at what level (ui or core) should calls to
> > gaim_sound_play_event() be made?
> > Currently, gaim makes calls to gaim_sound_play_event() from both
> > the ui and core levels. Most of the calls are made from gtkconv.c
> > (i.e. message received/sent, chat received/sent, etc). The buddy
> > logs in/out sounds were made from server.c in 1.5.0 and are made
> > from sound.c in HEAD (in response to appropriate signals). I would
> > assume most would agree that these calls should all be made at
> > either the ui or core level to provide a consistent interface to
> > libgaim users.
> > UI:
> > There is some tie between sound events and the gtk interface in
> > gaim. For example, each GaimGtkConversation window has its own
> > "enable sounds" menu option which determines allows the user to
> > mute individual conversation events. Because of this, it is much
> > easier to make the gaim_sound_play_event() calls from within the ui
> > layer to allow access to the necessary structures for determining
> > if a sound event should be played. I have submitted a patch
> > which uses this approach. It refactors the gaim_sound_play_event()
> > calls from gtkconv.c and sound.c into gtksound.c, making sounds
> > respond to appropriate signals. (gtkpounce and plugin sounds are
> > unaffected)
> > CORE:
> > If the calls were all made at the core level, then some code
> > duplication would be avoided, as libgaim users would not need to
> > make these calls. libgaim users could still replace the actual
> > mechanism which plays sounds (command, libao, etc). Implementing
> > this approach would likely require adding some additional state to
> > the GaimConversation structure.
> > Either way will mean some changes for libgaim users. If we go the
> > CORE route, they will need to stop calling gaim_sound_play_event()
> > for the buddy logs in/out events. If we go the UI route, they will
> > need to start handling the rest of the sounds. This should be a
> > fairly straight forward by looking at gtksound.c's signal handlers.
> > Thoughts?
> > -casey
> >  http://sourceforge.net/tracker/?
> > func=detail&aid=1273590&group_id=235&atid=300235