On 30/04/2016 17:30, Brent Busby wrote: > Edmond Orignac<edmond.orig...@wanadoo.fr> writes: > >> xmmixer was designed for use with OSS and is working at least on Linux >> with ALSA and OSS emulation. > > Since it's a Motif program, it would seem to be the best choice if we're > needing a mixer for CDE. I don't think it's absolutely necessary for > CDE to have a mixer though. People tend to use whatever sound apps > appeal to them and their uses, and not necessarily the one provided by > the desktop manager. > >> However, except for Slackware, Linux >> distributions have moved to PulseAudio, and I am unsure OSS >> compatibility remains. > > I'm running Gentoo, which lets you happily compile away all support and > requirements for PulseAudio. I also do a lot of recording and Midi work > on this machine, so it's a good thing that I can get rid of it, because > PulseAudio generally gets in the way of that sort of usage. I use Alsa > for regular desktop sound, and Jack for studio/recording apps. > > Again, I think this whole subject is a black hole you could disappear > into. It's probably best if CDE doesn't even attempt to do sound.
You are completely right. I was mentioning xmmixer as an example of an OSS sound mixing Motif application that is usable on Linux Slackware (or Gentoo) but probably not Linux Ubuntu or Fedora. It is also unclear to me whether xmmixer would be usable with the BSDs or OpenIndiana. So xmmixer should not be distributed with CDE. But someone could try to modify xmmixer to improve CDE integration and make it available separately via GitHub or Sourceforge, just like dtwinlist or Xarm. Also, if someone wants to make a Linux Live CD with CDE as the GUI, xmmixer could be included as a sound mixer if the underlying Linux OS is using the ALSA sound driver. > >> On Thu, Apr 28, 2016 at 08:09:27PM +0200, Danilo Schöneberg wrote: >>> Don't touch Webkit; it's a security nightmare and a bottomless pit for >>> time. > > Amen! CDE should leave the web to the web browsers. > >> For network applications, besides FTP, email clients and Web browsers, >> on could think of Motif IRC clients (Nebula is one, SmIRC is another one >> but apparently cannot be compiled with a recent g++), Motif instant >> messaging (https://github.com/gorais/gXipmsg) Motif RSS/Atom readers. > > IRC clients can also be exploited. CDE shouldn't be trying to provide > Internet client software of any kind really. If someone wants to write > Motif-based Internet applications, fine. They can even be linked from > CDE's web page so users will know about them. But it's a really bad > idea for CDE itself to be getting into the network software business. > I was suggesting Motif applications that could be used with CDE, not applications that should be included in CDE. You are right that since network applications need to be constantly reviewed and patched for security, they have no place in the basic CDE distribution. My proposition of considering CDE/Motif applications has to do with being able to get rid of network applications that don't just require Qt or GTK but the full KDE or GNOME infrastructure. >>> Unfortunately, some knuckleheads have decided that a novel's worth of JS >>> and CSS is the only way to show webpages...) > > Oh, that's when they're being kind. Now we have AJAX sites (<cough>, > <cough>..."Web 2.0"), which make JavaScript and CSS look minimalistic > and spartan in comparison. > > Anyway, I'm afraid of all this turning into bloat real fast if we're not > careful. To me, CDE doesn't need to do much more than what it does now, > but in a way that's compliant with modern UNIX systems. It doesn't need > Internet clients, video players, sound mixers, or a marching brass band. > It should just preserve the look and feel of the old 90's UNIX > workstations for people who still want that. > > One feature that would be very nice though (since it affects the > usability of the desktop itself) would be the ability to gracefully > handle things like a video player (not provided by CDE itself) going to > fullscreen, or a game going fullscreen, or a screen reconfiguration > using RandR on a desktop with multiple displays. Back in the days of > SparcStations and HPPA machines, it might have seemed reasonable that > the X desktop geometry would never change during a login session, or > that no application would ever try to take the whole screen, but these > days, that's a basic usability issue for even the most minimal usage. > ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
