Am 22.05.2013 20:09, schrieb Eric Hedekar: > This really was one of the most dramatic train/thread derailments I've seen > in a while. Impressive. > > As far as other desktop environments are concerned, part of me is in favour > of this mindset being adopted (as I've never left gnome despite Ubuntu > Studio's switch to xfce - I just don't like that DE). If a modular front > end was adopted then it would encourage wider usage and a better overall > design. However, what Hartmut may have been trying to state was that this > is development is probably not the best use of developer's time. There > have almost always been stability issues, bugs, and lack of documentation > in Ubuntu Studio that the user sees as more drastic to their workflow than > annoying quirks from the given DE. So yeah, apply force to the major > problems,
Exactly. Anyway, the problem is, that (no offence meant) there are more people out there, that can tweak and script desktop-stuff than coders, that are deep enough into the low-level affairs to be able to fix the real annoying issues... So if that can be helpful: I am perfectly satisfied by the US-Desktop! I like it, whenever I test it, I do not find anything that would need repair. Even though I use KDE for my day2day work including working with Ardour3, Guitarix, KDEnlive, testing Stuff like Bitwig and most new music-related software for Linux. I run it on Ubuntu and its KDE and USs XFCE are both just great. Good job, people! > but it would be a prudent philosophy to reduce the amount of > xfce-specific code that ships with the distro. We don't know how long into > the future the xfce platform will best suit our needs (very little warning > was given during the gnome/unity move that prompted our switch to xfce in > the first place), and the lack of DE-specific code the easier it will be > for those of us who love a different DE to just switch. Most wise. Productive work should be supported well by the DE but it should not depend on a specific desktop. BTW: If I compare stability and performance of Ardour3+many plugins + Guitarix under KDE, XFCE or Fluxbox I fail to see any practical impact of "bloat". Non of the 3 setups is enough to fill more than 2 thirds of my 8Gig RAM, that are a lot to me but not that special nowadays. And on my other machine I run comparable setups with 3Gigs RAM and with not much difference either.... So performancewise I do not think that a DE needs to be tweaked a lot. Expect maybe regarding dependencies to 3d-capabilities. best regards HZN > > -Eric Hedekar > > * > Eric Hedekar > *http://www.erichedekar.com > > > On Wed, May 22, 2013 at 10:32 AM, Ralf Mardorf > <[email protected]>wrote: > >> Getting audio working for audio production, with some bloated desktop >> environments is not very useful. Some desktop environemts do start a >> chunk of services by default to automagically enable usage for many >> things, so the user needs to customize those desktops for audio work, or >> somebody from the community has to do it. There are common workflows for >> pro-audio work and even while I could add a list of odd things, caused >> by Xfce, it's a sane choice to use it as the default for Ubuntu Studio. >> I'm using it on other Linux installs too. >> >> Pulseaudio is something that should be discussed. It's not an issue to >> have it installed and to disable it, but it's an issue for users who >> start sessions by scripts, if there is the need to start "qjackctl", but >> to kill "qjackctl.real" or what ever it's called ;). I don't remember >> what the "qjackctl"(.fake)-script does and can't take a look at it at >> the moment, but IIRC it did something that also could be started by >> qjackctl, instead of naming a script qjackctl and then let it start >> qjackctl.real. >> >> IMO it's already annoying if I need to start an app by it's name, but to >> kill it by killing python, however, this at least makes sense, while >> this qjackctl.thingy is an exotic Ubuntu Studio unique thing, that IMO >> isn't well thought out. A wrapper sometimes is useful, but this wrapper >> is strange. >> >> >> -- >> Ubuntu-Studio-devel mailing list >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel >> > > > -- Ubuntu-Studio-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
