summary of the aKademy meetings

[Dik Takken]

> Hi Dik,
> 
> A few questions:
> - How do you think should the applications "know" what Channel to use?

They don't. There could be a default channel that is used by all 
KDE applications, unless the user tells it to use a different channel.

> - How should the user select what Channel an app should use?

The application should include a standard channel selection section in 
it's configuration dialog, just like KSpell-enabled applications include 
the default KSpell configuration dialog. This dialog should query the 
KDE multimedia API for a list of channel names and descriptions.

> - How should the Channels be configured?

Each channel plugin should provide it's own configuration dialog, just 
like widget styles do. A KCM module should list all available channel 
plugins and show their configuration dialogs.

> - Since the Channel is a part of the interface the backend has to implement,
> it's pretty much a "plugin" already. Do you think that's enough, and if 
> not why not?

Yes, that would be enough. But if we want to use these plugins for sound 
processing in the near future, we need more channels than just a fixed set 
'notification sound, music, ...'. That's why I would suggest to change 
some definitions of the current API proposal to:

Group: Group of sound sources that use the same output channel. All 
applications outputting sound to the group 'notification-sound' will use 
the same (user-selectable) channel.

Channel: Plugin that takes care of processing sound output of KDE 
applications. 'processing' can mean anything, from just playing it though 
Arts/GStreamer/whatever to displaying visualisation graphics or harddisk 
recording.

This gives applications the choice between just sending sound to a group 
(which is what the proposed API does) and sending the sound to a specific 
channel (which is my suggested extension). Applications that only specify 
the desired output group will not implement the user-selectable channel 
feature.

> Ugh, just tried it. It's crashing a lot - somebody's been messing with 
> aRts again :-(

That's exactly what I mean.

Cheers,

Dik