David Walser <[EMAIL PROTECTED]> writes: > --- Guillaume Cottenceau <[EMAIL PROTECTED]> wrote: > > 1- do nothing, e.g. 99% of users which are under KDE > > will have > > the nice msg "sound card busy" and they need to > > guess they > > have to change the outpout plugin to "arts" > > (something they > > don't even know what it is) > > I would agree with you if this were the case all the > time. It's actually only a very small part of the > time that this will happen though, since arts releases > the sound device.
- it releases after a number of seconds (30 secs last time I checked, it may have been patched in the meantime) - then it means that xmms "steals" the DSP, and next KDE action will not produce a sound, which leads to the newbie asking herself why > > 2- keep a soundwrapper but instead of using esddsp > > or artdsp, > > dynamically change the contents of ~/.xmms/config > > behind the > > back of the user according to the plugin > > currently in use? > > > > I would favor -2- of course but as I said I don't > > know if this is > > really better. It seems your original mail favored > > -1-? Which I > > don't agree with, of course. > > Well, I like the idea of changing the user's output > plugin if they have a soundserver running, but I don't > know of a good way to do this (aka not sure a > soundwrapper is a good way). One problem is, users > can modify menu entries. For example, I modify my I'd say that if user modified menu entry, he's clever enough to know how to change output plugin from xmms preferences dialog. > user xmms one from "xmms" to "xmms -e %f" so files I > click are added to the playlist, rather than wiping it > out. Another user doing the same thing would wipe out > soundwrapper if they saw it there, and it probably > wouldn't make sense for it to be there either. Also > note that xmms -e works even if xmms isn't running, so > it can be used to start xmms. Does it map well to the menu system? A.k.a does the following patch is enough (ignoring soundwrapper pb)? --- /usr/lib/menu/xmms Fri Jan 11 07:51:05 2002 +++ /tmp/xmms Tue Feb 5 16:22:12 2002 @@ -3,6 +3,6 @@ section="Multimedia/Sound" \ title="Xmms" \ longtitle="Multimedia Player" \ -command="soundwrapper xmms" \ +command="soundwrapper xmms -e %f" \ mimetypes="video/mpeg;audio/x-mp3;audio/x-ogg;audio/x-mpegurl;audio/x-wav" \ icon="xmms.xpm" > Maybe the xmms config could be modified not when the > start xmms, but rather when they login to Gnome or > KDE. Do you think this is possible? I think it's possible but this is more of the decision of kde/gnome maintainers. David, FredC, WDYT of this idea? Maybe there is an idea of "first start of desktop" in kde and gnome and you could do (for Gnome for example) : if [ -r "$HOME/.xmms/config" ]; then perl -pi -e 's|output_plugin=.*|output_plugin=/usr/lib/xmms/Output/libesdout.so|' "$HOME/.xmms/config" else mkdir "$HOME/.xmms" echo -e "[xmms]\noutput_plugin=/usr/lib/xmms/Output/libesdout.so" > "$HOME/.xmms/config" fi > > PS : it would help people follow the discussion if > > you would > > answer the mails adding your comments *after* > > the relevant > > part of the mail, not before > > If there's more than one point to respond to, yes. > Otherwise it makes it easier to follow to reply up top. No because if the person haven't already read previous mails, he needs to scan the whole message, discover which is the highest level of indentation, read it, rescan, etc, which is very painful, opposedly if the mail is written as usual, it's just a top-down reading which is very much easier. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
