Le mar 12/08/2003 à 11:35, Damien Sandras a écrit : > That leads us to think about the way GM should use the plugins. > > For video, that is easy: all exising plugins are loaded, and if one of > the devices can be handled with a plugin, it appears in the list. It is > evident that a same device can only be used by one plugin at a time, > never more. > > For audio, that is more complication: all existing plugins are loaded, > but all devices will be usable by different plugins : OSS, ALSA, ESD. > > It means that you will have the following in the list of available > devices : > - OSS /dev/dsp > - ALSA /dev/dsp (the name will be different, but...) > - ESound /dev/dsp > > Using ALSA /dev/dsp as input (recording) with OSS /dev/dsp as output > won't work. It means that in most cases, using the same device > (/dev/dsp) with different plugins for output and input won't work. > Notice that ALSA means here native ALSA support and not ALSA with OSS > emulation. why not add here what you suggested for the mixer thing a bit after in this text? when the user choose ALSA as input it greys the OSS entries in output and just let accessible the ALSA ones, and the revers if the user choose OSS as input it greys the ALSA entries. > > I think that it is a bit complex for the user. So we have several > possibilities : > - Add a command-line parameter in GM that returns the available plugins, > and another one that permits to set the device to use in an hidden gconf > key. That way the user will only have to do it if he wants to use > something else than what his distribution ships. i don't think the lambda end-user won't know much more about the command line if he even doesn't know about ALSA nor OSS. How to set default behaviour at installation ? Does the user use ALSA or OSS? How to know?(I guess though that with new 2.6 serie kernel, it will by default ALSA, but....) > > > - Add a box in the prefs, where the user chooses what plugin he wants to > use. Problem here is that average users don't know what is ALSA or OSS > and they shouldn't know it. They should just have something that works. > > - Tell to packagers in distributions to only package one plugin, the one > they like. i think it's a thing to avoid....the user should have the choice...as he should have the choice of the OS he can have when he buys a PC ;P > > - Propose all devices to the user, he will get an error popup during > calls when it doesn't work. Problem here is that average users don't > know what is ALSA or OSS and they shouldn't know it. They should just > have something that works. could be done like that with what i suggested above, the greying thing. Though i agree that having three time the same device with different name for each downloaded plugin is not nice. :/ > > > The first solution is perhaps the one I like the most. But we have more > problems when we introduce ALSA : > - the mixer devices settings in GnomeMeeting doesn't make sense anymore, > only the player and recorder settings make sense, so there must be a way > in GM to hide them when ALSA is used > - OSS devices don't have a name, ALSA devices have a name > > Any comments? > > Julien, perhaps migrating my function that detects mixers to the plugin > is a good idea. If you look at their code, it already detects the > mixers, but there is no way to get the mixers list from the outside. > > Le lun 11/08/2003 à 20:36, PUYDT Julien a écrit : > > Le lun 11/08/2003 à 17:52, PUYDT Julien a écrit : > > > > > * INPUT->Input & OUTPUT->Output; > > > > Oh, well... I tested the new manager, and didn't see I had forgotten one > > such in the dlopen one... > > > > Snark Fabrice
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=