Lennart: >>> I thought about this already. However, c-g-p has a clean user >>> interface, and might be useful for end users, especially for testing >>> when designing themes. So I decided to stick it in bin. >> Still, it does not seem like a program an end user would ever want to >> run by hand. Why would an end user want to invoke a system sound? By >> nature they are sounds played by the system, not the user. >> >> Sun's ARC review process has made a suggestion that, on Solaris, we move >> this to libexec. Would the libcanberra community be agreeable if I >> provided a configure patch so that the location of this script could >> be configured? > > Hmm, would it be too much work for you guys to simply move the binary > when packaging?
We could. Though, most GNOME modules provide configure hooks so you can simply specify where to install such programs. Modules like D-Bus, GDM, and ESD are examples that leap to mind. > The tool might be useful for similar purposes as "zenity": for > scripting purposes. When run from zenity, it is being run from a program rather than a user. Normally libexec is used for things that are typically run from programs. > Or maybe even for tools like Pidgin which allow > you to enter the path for a program to call for playing event > sounds. I really think this tool might be useful to people -- not so > much end users -- but administrators and developers. Right, but advanced users and developers normally do not have any problem running things from libexecu. In general, it is bad practice to clutter up /usr/bin with executables that people, in all normal cases, do not use. > I'd prefer if people could rely on the existance of this tool in a > certain path. If someone could give a reasonable argument why it belongs in /usr/bin rather than /usr/libexec, then I am sure Sun's Architecture Review Committee would not have a problem with it in /usr/bin. Providing it for developer purposes, or for making it available for scripting are not strong examples, though. > Of course I can't tell you guys how to package this, but > please, if you move this, then do it by a Solaris-specific patch on > top of upstream libcanberra. If someone provides a working patch to specify where it is installed, why wouldn't it make sense to just accept it upstream? It seems sensible to allow people to configure the module as they want, rather than making people configure it when packaging. > I'd like libcanberra to be something that is a stable, reliable, > standards compliant API people can build on. If packagers like to > deviate from that, then this is fine, but I'd prefer not to take that > specific deviations upstream. It's the same with Nokia's patches to > include looking for .mp3 files in libcanberra. The standard everything > can agree on should not include MP3, due to patents, .... The > sound-theming-spec explicitly only supports .wav and .ogg. And because > we follow that standard, I don't want to see directly mp3 related > patches in libcanberra. And again, if Nokia likes to add .mp3-support > on top of libcanberra, they are very welcome to do so, but not > upstream. I can understand having issues with a non-free codec like MP3. However, not allowing patches upstream that allow libcanberra to be reasonably configured seems overly restrictive. If you insist, and if our ARC review process determines this really belongs in libexec, then we will obviously just patch the code as needed. It just seems odd. I have never before encountered module owners who had a problem with taking this sort of patch upstream before. >>> A while back, Marc-Andre Lureau from Nokia sent a patch for a gst >>> backend, which linked directly against the gst libraries. And was also >>> capable of cacheing prebuilt pipelines. I'd much rather see this patch >>> cleaned up and merged than the fork solution you proposed. Maybe you >>> guys can work together and make this work? >> I would love to, could you provide a pointer to the code? > > I think the latest code is here: > > https://tango.0pointer.de/pipermail/libcanberra-discuss/2008-June/000014.html > > (plus the following patches) > > Somehow I managed to ignore that second iteration of the patches and > didn't review them when Marc-Andre posted them. However, a few minutes > ago I finally reviewed them with Marc-Andre on IRC. He plans to rebase > them on current libcanberra. Great, does this mean that GStreamer will just be supported out-of-the-box with the next libcanberra release? That's great. Or do you need further help to make the code ready? >> While I see that stacking abstraction layers is a bit ugly, I think >> stacking libcanberra with PulseAudio is no worse than libcanberra with >> GStreamer or ESD. > > Oh, there's certainly a difference for the gst case. PA is an > abstraction layer only by side effect, while GStreamer in this cased > would be used only for its use as abstraction layer for sound > outputs. Still, I think in the Sun situation, having a GStreamer backend makes sense. Mostly because our underlying sound infrastructure is in the middle of a significant rewrite. So making use of GStreamer's abstracted sound output avoids doing needless work. I think we will likely directly integrate with Sun's audio interfaces after the rewrite is done. Brian _______________________________________________ libcanberra-discuss mailing list [email protected] https://tango.0pointer.de/mailman/listinfo/libcanberra-discuss
