No. They won't. Here's why:
It was a deliberate design decision to NOT utilize any of the existing Orbiter technology for qOrbiter, other than utilizing the Screen table (if for no other reason than Screen calls are everywhere in LinuxMCE, and we need to keep this as a means of delineating modality and encapsulating information.)
In short, Designer was very much like every in-house design tool used at a large company; it was written in a rush, it is buggy, it is unfinished, and it requires intimate knowledge of the underlying Orbiter code to really use effectively.
Past experience with trying to get people to use the tools, and to interact with sqlcvs was literally a disaster, people working in designer never got into the habit of keeping their database in sync. In addition, Orbiter itself has a wide variety of flaws which are a direct result of its design.
Orbiter was designed for things as they existed in 2003. Everything has changed. The need to pre-render everything, in addition to the complexities of trying to collapse different functional/aesthetic targets into shared functionality across multiple targets proved to create a system in which everything was lowest common denominator, Orbiter by its very design COULD NEVER make the best of its target devices. So what were we to do?
throw it all away. Rethink Orbiter as a DCE device running atop a declarative graphics engine (Qt Quick/QML running in Qt).
What does this give us?
It's easy to write QML, it's just properties and values ranging from physical properties, width, height, size, location, color, to transitions, like animation, relationship to other objects, etc. QML can be written by hand, created/manipulated in Qt Creator, or created as a part of a photoshop/GIMP exporter tool. It gives designers a way in, which is what we desperately need.
Bcause QML is so easily created and dealt with, it is actually possible to write whole sets of QML, with varying degrees of shared functionality, for any device that the qOrbiter can run on, make a QML for on screen TV, a QML for an android cell phone, a QML for iPad, one for a Nokia N9, each taking advantage of the capabilities of their target devices effectively, without a lowest common denominator choke-hold; Given that QML is easy to create, it can also be easy to maintain. It places ultimate flexibility in the hands of the UI designer to do what they do best: design.
Its flexibility has already been proven:
* a basic skin meant to develop qOrbiter's functionality
* a test port of Aeon from XBMC, as proof that qOrbiter CAN do flashy-flashy-zoomy-zoomy-blurry-blurry-crispy-shiny-shiny,
* a skin for the Nokia N9, built from scratch using the Nokia Harmattan UI components, to match the UI guidelines for Nokia N9 applications.
the underlying Qt toolkit is present on many platforms, Linux, PC, Mac, in addition to being the standard toolkit for Symbian, and MeeGo. An active native port of Qt to Android (using JNI bindings to the Android NDK) is also available and being actively ported to. Ports also exist for WebOS, and iOS, in addition to Windows Phone.
In short, Qt is everywhere, either overtly; as part of the system level toolkit chain, or as a port.
If this doesn't vindicate the applicability of this whole approach, I don't know what will.
-Thom
