[ubuntu-studio-devel] -controls

[Ralf Mardorf]

Hi,

especiall user-friendly apps should keep things simple. Don't try to 
cover all posssible usecases. If somebody wants to use an USB 
interface, then it doesn't require some ominous secundary master 
interface. Assuming a user unpluggs an USB audio interface, then the 
user needs to change the settings, e.g. by using another 
preset/profile. Its easier to follow a good documentation or to ask in 
a forum, how to do settings, than to use an app, that conflicts with 
the common way to set up those things. If you think available common 
used apps don't cover usecases, its better to report it upstream, than 
to write an app that conflicts with common used apps. What if a user 
does add a ferquency scaling tool to the panel? Keep Ubuntu Studio 
compatible with distros that follow a classic unix alike approach. One 
app for one task. No fancy GUI, if a scrit could do. Ubuntu Studio 
makes already a lot of things very unusual and it's more a mess, than 
useful. Unusual menues, bizarre sound server defaults. Actually you 
cover your personal prefferences, not what a majority of user consider 
as beeing useful. Let alone that you even ignore the way Ubuntu goes, 
in regards to systemd. Again, don't use init.d anymore, write a systemd 
unit, this is the official way Ubuntu goes. 

Even if you think, that the app should cover CPU frequency scaling, 
than make it a user session setting, not a boot time setting. Assuming 
a school or public studio provides one machine with several user 
accounts, they would run in issues if everyboddy could change boot time 
settings. If accounds quire different settings when starting a session, 
provide your auto-start settings from boot to session auto-start. This 
would even not conflict with the Debian/Ubuntu CPU frequency scaling 
startup script. 

Actially you are writing an app, without thinking about the the 
structure in the first place. First plan the app, than write the app, 
don' t mix planning with writing. 

2 Cents,
Ralf