Re: 3.2: gjs/seed, QML?

[Alberto Mardegan <mardy users sourceforge net>]

Hi,

On 04/25/2011 04:20 PM, Emmanuele Bassi wrote:
[...]
> if we want declarative UIs then we shouldn't look further away than a
> web rendering engine, HTML5 and JavaScript, and exposing the GNOME
> platform through ad hoc JS APIs.

This is also a viable way indeed. Though my gut feeling, and some
concrete tests [0], hints me that performance-wise the way might be
steep for HTML5.

[...]
> QML is a badly designed JSON-look-alike with JavaScript evaluated on
> every right-hand-side definition, and it requires dropping into C++
> and Qt if you want to have reasonable performance and decent logic
> abstraction to avoid the "write once, throw away immediately after"
> syndrome.

Indeed, but you'll have to drop into the native code for any declarative
UI language.

[...]
> I tried QML, talked to people using it daily, saw real-world usage of
> it, and even talked to its creators - and I am constantly amazed how
> somebody could ever think that conflating UI description and logic
> into the same ad hoc, barely specified language was a good idea.

I believe it's part of its strength, instead. I've seen way too many
times developers having to change/hack their code to produce a cool
effect (or just a layout) that the UI designer wanted so badly, but that
the theming engine was unable to deliver.
And it's not also about theming; sometimes you want to use a completely
different widget, a different animation, a slightly different UI
behaviour that cannot be achieved by just changing the application style.
At the end, despite having separate theme files (CSS or other), changing
a UI in a non trivial way often requires changing the code.
And I'm not talking about migrating a desktop UI to a tablet or to a
mobile device (even if indeed I believe that the reasoning applies here
much more strongly), but at least according to my experience with Nokia
UIs (Gtk, Hildon and then MeeGoTouch), the fantasy of UI designers has
always surpassed the capabilities of the theming engine.


Anyway, be it a QML-like or a HTML5 based language, I believe that GNOME
needs a declarative UI engine.
Application logic (unless it's really trivial) should still be coded in
a native language, with bindings that allow the objects to be used from
the UI layer. As I see it, a successful UI language should allow one to:

- design the UI, statically
- design all the UI interactions
- design the animations
- allow for easy themability
- allow for simple code snippets, which for example could be used for
  field validation
- facilitate code reuse
- write the application core in one's favourite language, and provide
  for different "skins" (which is more than a theme, as they could
  contain totally different UI flows) to be used in different contexts:
  GNOME desktop, KDE, touchscreen device, small screen device, etc.


So, not just the theming, but also the fact whether a control should be
a switch or a checkbox, and even whether it should be not shown at all,
all these are parts I consider to be "UI" and I'd like them to be
modifiable without rewriting my application's code.
IMHO QML can do this quite effectively; but then, I'm not claiming it's
the only one (it's just the one I'm more familiar with).

Ciao,
  Alberto


[0]:
http://www.qiliang.net/blog/wp-content/uploads/2010/09/HTML5_QML_Comparison_redist.pdf

-- 
http://blog.mardy.it <- geek in un lingua international!