Emanuel Rumpf wrote:
> Are you actually suggesting me to read the manuals of all the programs
Some folk learn things that way. Your mileage may vary!
> An application that doesn't attend to the GUI may create
An application that has a slick, polished GUI full of 'eye candy' always
makes me wonder that they put all their effort into the GUI, and the
internals are all messed up. Like those common US high school kids'
cars, with a new fancy paint job and custom muffler covering an engine
that runs like crap when it runs at all.
You need a balance. And the smaller the development team, the less is
available to achieve that balance. So I'd rather have the team put its
effort into making the engine run well rather than putting a custom
paint job on it.
My opinion about software architecture: every app should be written in
two parts. The first is the back end that does all the real work, and
comes complete with a documented API usable from as many other languages
even have a web UI for the app.) The second is the front end, the UI. If
the two parts are properly separated, you can have as many different UIs
for the application as there are people who care to program a UI for it.
So you can have a complex advanced UI for the experienced user with
great domain knowledge, you can have a simple "Beginniners" UI (such as
a 'Wizard" style UI) for the casual for first time user, you can have a
text UI for blind or visually-challenged users, etc. You can even have
the back end run on a completely different machine such as a server, and
have the UI running on a client workstation; quite useful for such
situations as a smartphone UI client that can tap the hardware of the
backend for the heavy lifting.
SuperCollider works like that. Seems like good futureproofing to me,
without locking things into a particular language for the UI.
authenticity, honesty, community
Linux-audio-user mailing list