Making Studio work with more than one DE

[Hartmut Noack]

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
> <ralf.mardorf at alice-dsl.net>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 lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
>>
> 
> 
>