vendredi 17 juillet 2009

What if GTK+ 4.0 was ... HTML/CSS/Javascript ? Part I

Following recent activities on the GTK theming/graphical overhaul front, this post exposes some of my thoughts on a possible evolution path.
This first part explains some of the current identified short-comings and tries to dress the profile of the ideal UI toolkit. In the next post I'll try to explain the technical possibilities to go further this road.

Nowadays, GTK+ and most of the competing toolkits keeps the user interface creation a developer's affair when the web allows designer and usability experts to directly influence the aspect of the application. This is mainly caused by a steep learning curve and a lake of user friendly authoring tools.
Also recent efforts by the web standards bodies make them very appealing solutions for highly graphic, dynamic and interactive interfaces.

Current State :

GTK+ is the graphical toolkit used by several mainstream software projects. In a non-exhaustive way, we can cite the Gimp, the Gnome Desktop, Firefox and (in their Linux incarnations).

It provides developers a way to programatically define/design the user interface of their software : where to put a button, a text entry or a selectable list for example.

It is also possible to declaratively define a GTK UI using the Glade editor and the GtkBuilder XML dialect. The coder binds the events generated by the UI elements (or widgets) to «business» code/services.
GTK+ currently misses some features found in more «modern» toolkits like animations support, canvas, free form layout, declarative theming.

GTK+ is built using GObject which bring dynamic object oriented concepts to the old-but-good C without scarifying the ability to easily bind the code to higher level languages like Python or Javascript.
The GObject ecosystem spun a lot of interesting technologies in the form of libraries mostly developed within the Gnome project. To name a few, we can cite the GStreamer multimedia framework, GIO, Avahi, EDS, PolicyKit.
The fact that GTK+ and those services share a common object system makes them easy to integrate in a GTK app, and thus help GTK+ staying relevant.In the same vein, GTK+ UIs can easily be plugged to DBus services.

New efforts to make the theming system more flexible like a CSS theme engine. By this leave flexible layouting on the side.
Some discussion is also going on the future of the metacity theming.

Pros :
  • Multi-platform
  • Community and commercially backed (Red Hat, Novel, Mozilla Foundation)
  • Lots of language bindings
  • Wide range of target system : Nokia Maemo, Moblin, Gnome, OpenMoko...
  • Mature and alive code-base
  • Rich eco-system of GObject libraries (DBus, GStreamer, GIO, Avahi, EDS, PolicyKit...)
  • Enforce a coherence under most linux boxes

Cons :
  • shrinking numbers of contributors
  • Hard to grasp as mainly programatic
  • Lake of "Bling" and usability/artistic freedom : canvas, animation/transition, freeform layout, declarative theming

Summing up, the
ideal UI toolkit would :
  • be multi-platform
  • be community and commercially backed
  • have a lots of language bindings
  • be avalaible on a Wide range of target system
  • have a Mature and alive code-base
  • could benefit from the rich eco-system of GObject libraries
  • enforce a coherence under most linux boxes
  • have a big following, including developers, users, authoring tools
  • be Declarative
  • have very flexible styling and layouting
  • provide advanced graphical capabilities as animation, transformation etc...

But wait... Doesn't
HTML/Javascript/CSS match most, if not all, of these criterias ?

1 commentaire:

  1. yeah pretty much....I've been wondering recently if wayland removes the age old problem of the x11 protocol in favour of something far simpler, can we just strap webkit as a desktop manager and start writing apps with a modified box model (circumventing html's left->right->top->down) and use all the tools we currently have online, but on the desktop.