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.
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 Openoffice.org (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.
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 ?
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.
RépondreSupprimer