- I don't think that Flash is a good choice for the UI3 basis: it is based on different ideas, it is used for different purposes and it is not open. In fact, the biggest common thing with UI3 in Flash is that it is sometimes used for building user interfaces
- The same applies to the Gnash - with addition that Gnash (in the sense of development direction) is a tail of Flash pony: Gnash has to follow the Flash features and evolution. It will never be the separate.
- Regarding the design of UI3: I am not sure that it is a good idea to create it from scratch, because of the following:
0) most of the time it will be not feature-ready and incomplete, so everybody will still use the UI2 and see the "stall in the development"
1) if you want to design it from scratch, you will most probably have to hack all and every piece in whole LinuxMCE system, to propagate new ideas/design approaches - or you will restrict your "open mind" to some subset of things (say, "UI3 has to coexist nicely with applications A,B,C") thus losing half of "from scratch" benefits
2) parts of discussion, especially "big list of all required features and possible uses" reminds me about the well known "second-system" effect ( http://en.wikipedia.org/wiki/Second-system_effect
) - I am afraid this attempt can fail because of too big initial expectations/design features. It should be really lightweight
3) I don't see the list of "problems" with UI2 except that it sometimes lacks developers' attention - wouldn't it be better to start refactoring the existing code, creating "UI evolution roadmap", adding features, switching to new approaches/implementation, etc.
- Regarding the IDE: don't care too much about the big and powerful IDE at the beginning of journey: if the development be successful, the IDE will appear. Of course, certain ideas should be taken into account, such as - it is always easier to modify human-readable file that to issue SQL queries. Like with websites - webdesigners doesn't use IDE 100% of time - they spend a lot of time in notepad-like text editors, tweaking the HTML,CSS,JS,etc.
- Personally I think that "evolution" is better than "revolution" and would vote for the creating UI2.1, UI2.2 etc. with extra features/improvements
- For enhancing the usability, I would suggest to ask someone who interested to modify LinuxMCE current UI and see what are the common issues/things-hard-to-do - and compose a list of them and eliminate/optimize them one-by-one.Now, couple of random thoughts related to the above description of "desired features" and logic of UI design:
- Description of objects properties inheritance and conditional properties evaluation, reminds me about HTML+CSS style of UI implementation - does anybody else see this analogy? Maybe we could utilize it and define the engine layouts in kind of XML-ish format. And use CSS-analogue approach for defining stylesheets, too.
- Targeting the same interface to all possible devices doesn't look as a good approach to me: compare, e.g. big 50" plasma TV and ~160x120px cellphone screen: trying to have the same screen for them, even styled differently doesn't seem feasible. Or the result will be non-optimal. So, why not divide all devices into few categories, based say on screen size, CPU power and network speed:
screen size: high (TVs and displays), medium (PDAs, Cisco-like phones), low (mobile phones)
cpu/rendering power: high ( PCs ), medium (PDAs, Cisco-like phones), low (mobile phones)
network speed: high (100/1000Mbit), medium (WiFi), low (Bluetooth)
The ranges can be more flexible of course
Of course this doesn't mean that there should be 3*3*3=27 different interfaces: the main could be the screen size (so there should be 3 different interfaces), the CPU power will determine which effects are on/off and if the device is 'active renderer' (like Orbiter) or passive (like plain bitmap display with off-screen renderer sitting e.g. on core). The network speed will allow to decide what media can be streamed, if the device can work as "bitmap display" or should be even falled back to text-only interface (if network is too slow).
So it is kind of "enumeration of capabilities" for different target devices and tuning/selecting proper UI for them.
- Finally, if creating UI3 from scratch will be selected, I would suggest to utilize 3D-games developers experience - there are many nice tricks/ideas that can be used to create nice and extensible interface. "World organization" (for UI it is about widgets, and binding the actions to them), scripting, skins and even audio/video playback - all this is present in modern games. Including need of scaling to different resolution (within some range).