<div dir="ltr"><div><div>This really was one of the most dramatic train/thread derailments I've seen in a while.  Impressive.<br><br></div>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, 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.<br>

<br></div>-Eric Hedekar<br></div><div class="gmail_extra"><br clear="all"><div><u><br>Eric Hedekar                      <br></u><a href="http://www.erichedekar.com" target="_blank">http://www.erichedekar.com</a><br></div>


<br><br><div class="gmail_quote">On Wed, May 22, 2013 at 10:32 AM, Ralf Mardorf <span dir="ltr"><<a href="mailto:ralf.mardorf@alice-dsl.net" target="_blank">ralf.mardorf@alice-dsl.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Getting audio working for audio production, with some bloated desktop<br>
environments is not very useful. Some desktop environemts do start a<br>
chunk of services by default to automagically enable usage for many<br>
things, so the user needs to customize those desktops for audio work, or<br>
somebody from the community has to do it. There are common workflows for<br>
pro-audio work and even while I could add a list of odd things, caused<br>
by Xfce, it's a sane choice to use it as the default for Ubuntu Studio.<br>
I'm using it on other Linux installs too.<br>
<br>
Pulseaudio is something that should be discussed. It's not an issue to<br>
have it installed and to disable it, but it's an issue for users who<br>
start sessions by scripts, if there is the need to start "qjackctl", but<br>
to kill "qjackctl.real" or what ever it's called ;). I don't remember<br>
what the "qjackctl"(.fake)-script does and can't take a look at it at<br>
the moment, but IIRC it did something that also could be started by<br>
qjackctl, instead of naming a script qjackctl and then let it start<br>
qjackctl.real.<br>
<br>
IMO it's already annoying if I need to start an app by it's name, but to<br>
kill it by killing python, however, this at least makes sense, while<br>
this qjackctl.thingy is an exotic Ubuntu Studio unique thing, that IMO<br>
isn't well thought out. A wrapper sometimes is useful, but this wrapper<br>
is strange.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
--<br>
Ubuntu-Studio-devel mailing list<br>
<a href="mailto:Ubuntu-Studio-devel@lists.ubuntu.com">Ubuntu-Studio-devel@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel</a><br>
</div></div></blockquote></div><br></div>