Making Studio work with more than one DE

Eric Hedekar afterthebeep at
Wed May 22 18:09:38 UTC 2013

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, 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.

-Eric Hedekar

Eric Hedekar

On Wed, May 22, 2013 at 10:32 AM, Ralf Mardorf
<ralf.mardorf at>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
> Ubuntu-Studio-devel at
> Modify settings or unsubscribe at:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Ubuntu-Studio-devel mailing list