2011/8/11 david <gnome@xxxxxxxxxxxxx>: > Emanuel Rumpf wrote: > > >> An application that doesn't attend to the GUI may create >> the impression that internals might be equally messed up. > > 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. > That's the other extreme. In my experience less spread, at least in the open software world. In closed, commercial applications OTOH ... > > 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. > Agreed. > 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 as > possible. (If the API was usable from Java or Javascript, you could 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. > Sounds like a good approach :) What may be the best cross-platform approach for UI <--> Backend communication ? Sockets ? Shared mem. ? Which protocols ? D-bus ? Any recommendable C-libs ? -- E.R. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
