« on: August 30, 2007, 05:10:29 pm »
Building an eye-candy GUI is all well and good. Visual presentation _is_ important, and given the code-base and the current limitations of the Orbiter, this IS _a_ top priority.
With that said...
I do believe that a great amount of detail needs to be spent on making sure that the existing functionality (and I am talking from the user perspective), works, and works well, remember...this is an appliance, it needs to work as such. I'm not talking about INSTALLATION, i'm talking about AFTER the installation hurdle has been crossed and you're staring at a working orbiter, like making sure that:
* if we go into KDE, Arts doesn't clobber the soundcard, so the orbiter phone will still function.
* messaging breakdown when using a Sony VAIO jukebox (i've literally had the entire DCE router restart even when a rip was in progress, which TOTALLY causes even more bizarre behaviour with the jukebox as you continue using it.)
* button interaction, when I press a button, I want to know i pressed the button, even a simple color change, a blip sound, something.
* making sure all remote types can access all of the exposed UI elements. (Windows MCE remotes currently can't deal with the gesture rose for things like changing channel with the rotating guide,.. the MCE arrow keys are completely useless.)
* making sure auto-detected networked storage devices work
What about sqlCVS?
What about altering remote assistance for our needs?
What about the missing tools so that we can get working NOW?
The important thing to note here is that, yes, shiny interfaces good.. but it's also about the protocols and interfaces, making them cleanly understood.... I for one would like to see a Motorola RAZR (J2ME) orbiter, don't think we can port the Qt4 one to that...
Paul, you say there are discussions started with KDE, Pluto, and Trolltech, is there a public forum so that we can be in the loop? Bring them here, or can we go there?
(yes, I _am_ being a persistent, tenacious, and arrogant bastard. I've seen far too many good projects go up in flames because the developers didn't make themselves communicate on a regular basis.)