Where WebOS got it right: Text-based UI layer and applications

Taking advantage of the demise of HP webOS hardware venture, an orphan tablet and phone reached my postbox recently. As a traditionalist computer geek, I was interested to live the so-called post-PC experience using the beloved webOS.

The two form factors hardware feel robust and nice to handle, notably the perfect balance of usability and portability of the Pré 3.
The user experience is as enjoying and intuitive as stated in reviews describing it in great length. Thus, I wont detail it further.

The active applications developers community  is surprising for stray dying platform. Both official and homebrew channels provide maintained software. Firesales and quite flat learning curve broke barriers. Somehow they did something right here.

Fixes and extentions to standard shell and applications are distributed by Préware.  Being defined as textual data, easily diffeable and patcheable, the environment is simple to modify and extend at runtime location. The Holly Trinity HTML/CSS/javascript makes fiddling with the system accessible to casual developers.
Applications, both system and third-parties, are actually editable data.

The Shell's javascript nature and its you-shall-do-what-you-want extensions mechanism, dynamic languages bindings, GtkBuilder and CSS-enabled Gtk+ tend to offer the same advantages to the Gnome platform.
Though, modifying core modules (mailer, contacts directory, web browser, to name a few) ain't a straight-forward process. Furthermore, patches packaging is not supported by major distributions provisioning services.

Making the whole environment patcheable in-situ without restrictive extensions points might prove fragile and error-prone but offer a freedom rarely seen even in free software. Preware packages supports patch reversion in case of issue or change of mind.
In the interim of having a common extension mechanism ala OSGi and robust well-defined extension points, local-patching might catalyze the transition from user/applications developer to contributor. Editing a system file and creating a patch is a fast process to create a deviation from a base system compared to getting the source, editing building and packaging.
Proposed patches for distribution should be deeply reviewed to enforce compatibility, security and quality.

In a read-only base system future, patches could be deployed at boot time using FS overlays as found in Fedora USB image, ZFS or Btrfs. Or why not a system-wide git repository ?

What's your take ?

Third-party developers experience... Where are we ?

Apple iOS application-centered focus and marketing made third party applications ecosystem a decisive aspect of user capture.  Solution life-cycle and attractiveness are increased by external developers adding each and every use cases imaginable. Even digitally farting.
Thus recruiting third party applications developers is an increasing challenge for a platform competitiveness and userbase/contributions growth.

The monetary insensitive of commercial platforms is certainly a decisive argument, but we may have better to propose with our warm and human-sized community, independence vis-a-vis a single provider, good-doing and ethical principles. And beer events.

The introduction to our technologies and community should strive to be as painless and entertaining as possible while matching the developer knowledge-thirst, a common disease upon us and a huge motivation catalyzer.

A fun, lean and streamlined developer experience may attract the more feature-oriented developers that enjoy watching their ideas materialize as an applications. From project bootstrap to installation on user system.
Those more into technology would enjoy our mature but ever-growing sets of tools, libraries and services.
Picking their interest is an occasion to convince them of the benefits of free software development and maybe have them help improve our common playground.

It is my opinion that the current offering of Gnome in that regard is not as good as it could be. The learning curve to become a proficient application developer is quite steep beginning by choosing a language and setting up a development environment. Coding, scheduling, sharing, testing and distributing an application, all suffer from barriers and complexity. But that can be improved, right ?

By digging into following platforms, I'll try to identify what helps makes a good developer experience, or a great one even.

• Apple iOS: Great documentation and tooling. Self-contained easy-to-setup SDK that handle application life-cycle from development to distribution. Code is written in Objective-C/Cocoa using the XCode IDE. No real 3rd party libraries community.
• Google Android: Regarded as practical API-wise and well-documented. Self-contained easy-to-setup SDK that handle application life-cycle from development to distribution. Using of the Java language, it benefits from its gigantic set of tools (IDEs, build bots, continuous integration) and libraries 
• Eclipse RCP + XScalaWT: Provide a great module mechanism (OSGi) and a lot of services commonly found in applications. Self-contained easy-to-setup SDK that handle application life-cycle from development to distribution. A rich ecosystem of 3rd parties modules avoid having to reinvent the wheel. Obviously development happens in Eclipse IDE in any language supported by the JVM. Scala peppered with a nice SWT DSL will be used. 
• the “Web Platform”: Applications development using our century franca-lingua: HTML/CSS/JS. With years of omnipresence, tools, libraries, documentation and community are unmatched. Still, application development requires system resources access, but not everything is standardized. Also javascript might prove a constraint for security, proper testing, static analysis and performance.
• HP WebOS: Based on web technologies, both Mojo and Enyo provide access to lower-level services to webby UIs. Offer great tooling and distribution channel (but nobidy on the other end)
• Gnome: versatile and complete SDKs, without much constraint in term of technology and possibilities. Might lake a coherent developer story with tools, conventions and processes to guide the developer
• Qt: not experienced yet.

For each, I'll share the full process of bootstrapping, creating and distributing a simple app and present thee communication channels, documentation, processes and tools. Good ideas might be picked here and there.

Then, I’ll match the findings with the current Gnome offering, with *personal* opinions on opportunities to fill holes.

Growing SeedKit

SeedKit being more than a year old, now is a good time to do a retrospective, get an overview of what's coming next and where you could help.

By lowering the entry barrier for building, distributing and maintaining a Gnome application, the SeedKit project wants to attract new contributors and make current developers' life easier.
The approach taken is simple: let developers reuse their web UI development skills, tools and community.
Furthermore, the resulting UIs will be more flexible, eyes-pleasing and dynamic, thanks to the amazing progress of the HTML/CSS/JS threesome in WebKitGtk and Seed.

So where are we now ?

We currently provide an GTK widget rendering HTML/CSS/JS content where native libraries and services are accessible from the JavaScript context.
DBus services, GObjects or custom code can be invoked and/or bound to DOM elements data and events.
End result: building an HTML UI communicating with local lower level systems is now possible. This might prove a great alternative to Gtk+ or Clutter.

For the full-blown SeedKit applications (lets call them hybrid for a minute) scenario, a runtime environment is provided. For now it only consists of a simple launcher but will hopefully be augmented with a standard library and a set of guidelines (mostly following the HIG 3) to ensure consistency among hybrids and 'classic' applications.

So yeah, you can run your hybrid application on your computer... Great, but how does it fall and deploy in the hands of the end-user you might ask ?

That's what is coming next.
We have no intention to build a versioning, dependencies and provisioning management system from scratch. Thus hybrid applications should be easily installed from distributions channels, namely packages and repositories.
Thus templates for .desktop files, rpm specs and debian recipes will be added soon to make the packaging a breeze.
If you are a bored packaging wizard, drop by the seedkit-devel list, we need you!

Another missing piece is the aforementioned standard library. HTML alone is far from providing the high-level concepts required to express a user interface naturally (sliders, modal windows, tree, list for example). Web developers already provided solutions in the form of libraries like Mootool, JQuery or ExtJs.
jQuery and its UI widgets will become the favoured target and will be packaged with each application or depended upon if provided by distribution's package. Some help with converting Gtk's Adwaita CSS to jQuery-ui would be great.
Also, we'll build jQuery-esque convenience wrappers for common operations like signals/events connection, data binding, internationalization and files access.

The vision and execution are still in their infancy so now is the good time for you to get involved, shape them to your tastes and need and have fun building the next big thing together ! Gnome developers, designers, web developers, translators, bug hunters will be welcomed with open arms.

Lets get in touch at the the Desktop Summit in Berlin, I'll hopefully present SeedKit in a BoF session.

Announcing the SeedKit library and SeedKit Viewer 0.1 release.

The SeedKit project is happy to announce the simultaneous releases of both the SeedKit library and viewer.

It is the first ever release of the SeedKit project.

SeedKit view's consumers, documentation writer, hybrid applications developers and contributors are welcome to test/modify/contribute. Any help gladly appreciated !

Notes

• This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production.
• No API compatibility guarantee is provided. The interfaces are susceptible to change until the 1.0 release.
• to pre-release testers : the project was split recently and changed its license terms, please update your copy of the original repository and clone the viewer one (see bellow).

What does it ?

With SeedKit, a developer can choose to define the user interface of a native application in pure web standard technologies (HTML/CSS/Javascript).

Alternatively a developer of an existing GTK+ application can embed a SeedKit view within the current interface.

What is it ?

The SeedKit project currently consists of two modules:

• SeedKit library: HTML view Gtk+ widget with access to lower-level libraries and systems within its Javascript environment. It is build around the Gtk+ port of WebKit and Seed [1]. Licensed under the LGPL 3+ terms.
• SeedKit viewer: a simple command-line viewer/launcher for applications whose views are defined in pure web standard technologies, while accessing lower-level libraries and systems (hybrid applications). Licensed under the GPL 3+ terms.

Examples of hybrid applications are provided in the examples/ directory of the seedkit-viewer package.

Download

SeedKit release packages are currently hosted on a personal public dropbox folder until a proper solution is found.

SeedKit library 0.1: http://dl.dropbox.com/u/5746554/seedkit-releases/seedkit-0.1.tar.gz

SeedKit viewer 0.1: http://dl.dropbox.com/u/5746554/seedkit-releases/seedkit-viewer-0.1.tar.gz

To follow the SeedKit development, you should clone the following repositories on Gitorious:

git://gitorious.org/seedkit/seedkit.git

git://gitorious.org/~scaroo/seedkit/seedkit-viewer.git

Building and installing

The SeedKit library compilation depends on the presence of :

* gtk-3.0 >= 2.90

* webkit-3.0 >= 1.3.3

* seed >= 2.31.5

The viewer only depends on the SeedKit library's presence.

Both can be compiled and install using the classic "./configure && make && sudo make install" sequence.

Contact

Concidering its low maturity, expect to experience bugs and misbehavior. Please report any issue, expectation or remark to the SeedKit mailing-list at seedkit-list@gnome.org until a proper bug-tracker is be set or used (hello sysadmin team ;)

Of course, drop a mail on the list if you want to participate in the SeedKit development too.

Happy coding !

News and noteworthy in the SeedKit land

Due to my current professional engagements, SeedKit development slowed down the last few week on my side.

This did not stop others to take the flame with contributions from Javier Jardón and Elliot Smith related to the build system (autotools).

Also a first third-party application is currently being developed by Alan Forbes. This log viewer is a great showcase for SeedKit. Thumbs up.

Announcing SeedKit project.

Those last few days, I had the oportunity to spend some time on my pet projects. Being far enough for now and waiting gladly for some external help, I am ready to announce one of them : SeedKit.

SeedKit is a runtime environment for hybrid Web-ui/GObject applications.

Taking advantage of Seed bug #612590, SeedKit provides a Webview whose Javascript context is filled with Seed-provided GObject symbols.

It makes possible the creation of a ui using standard Web technologies, such as JS, CSS3 and HTML5 bound to lower level events and behaviours of GObject based libs and DBus services (WIP).

All it requires is the path to an html file (defaulting to ui.html in CWD). This file can include js files calling into GIR-provided symbols.

You can pass --inspector to be able to inspect dom elements dynamically and --script=file.js for a custom initialization javascript file.
Some samples (Notifications, GIO, DBus...)are provided in the examples dir.

The project is still in its infacy and suffers from serious issues. Notably the DBus binding is not in a working state, seems like the js context is cleared after first-level imports or something.

TODO (as of now) :
- define a system-wide css file for common theming.
- add a developer mode, with reloading button

- create a bug tracker, an agile management tool, a website, ML
- fix DBus binding (exposes a customly created dbus connection within native code ?)
- add samples of web-services integration ( Evolution Contacts on a google map ?)
- a runtime for widgets ?
- see what s come next :)

The sources can be grabbed at http://gitorious.org/seedkit and you can mail me at scaroo@gmail.com, in the wait of a proper ML.

Any code, help or idea appreciated. Contributions welcomed :)

A plead for a SSB generator and execution environement for Gnome

This paper describes a proposed solution for a SSB system aimed at the Gnome Desktop. Having various web applications more tightly integrated within the user desktop would be a step toward the unification of the web and the native world.

What is an SSB ?

dixit Wikipedia : '
A site-specific browser (SSB) is a software application that is dedicated to accessing pages from a single source (site) on a computer network such as the Internet or a private intranet. SSBs typically simplify the more complex functions of a web browser by excluding the menus, toolbars and browser chrome associated with functions that are external to the workings of a single site.
'
What are the benefits of an SSB compared to standard browsing ?

• Space fully dedicated to web application content
• System integration (application launcher, notifications, menu, icon badges, local storage...)
• Standard windows' interaction, being handled by the WM/Shell

Existing Solutions
The SSB approach is already applied by several solutions, with diferents objectives and technical directon :

• Mozilla Prism : firefox extension allowing the creation of a SSB from the currently browsed web page. Of course, the execution environnement is built around Gecko.
• Fluid : standalone SSB creator and Webkit based execution environment with system integration (dock icon badges, Growl notification) and some goodies (userscripts, custom CSS)
• Adobe Air : Support application development using standard web technologies, beside Flash content. Embeds WebKit.

Proposed Solution

• a Webkit based SSB execution environnement, a chromeless WebView providing sytem integration
• An Desktop entry creator, following http://standards.freedesktop.org/desktop-entry-spec
• an Epiphany extension creating an SSB from the currently browsed Web App.

Desktop entry creator

• Generates .desktop file from user-defined values for the URL, the name and icon path of the SSB
• Provides right arguments to the execution environnement
• Defaults to Website favicon if no icon specified

Webkit based SSB execution environnement :

• One process per SSB
• Chromeless WebView
• Restricted access to the user-defined Web App domain
• Each SSB has their own cookie storage
• Use site specific javascript logic for system integration (ex: get the right value in the DOM for the number of unread messages to be displayed in the notification and/or badge)

System Integration implementation

• Applications launcher in Gnome menus
• Icon Badge (ex : number of unread mail)
• Notification system integration with libnotify using Seed or GtkWebkit DOM bindings ("You've got a mail")
• Application menu by generating specific GtkBuilder files and linking event using Seed or GtkWebkit DOM bindings
• Local storage, possibly Google Gears

The project will be hosted on Gitorious and welcome any contribution being code, documentation, or simply advices.

The first draft code will be commited sometime in the next week, the current state being nearly none :)

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 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.

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 ?