The week in qooxdoo (2014-04-04)

Welcome to a weekly status update.

Progress in pointer Branch

We’ve made good progress in the pointer branch and are very excited about the result. If you are curious, now it’s time for you to get started! Thanks in advance for your support.

Check out the pointer branch and build your app with it. If you have any error, make sure to read the preliminary release notes for qooxdoo 4.0, which holds more information on what API changed. Don’t worry about the long list of API changes. Only a few changes are to the public API (in the list the terms in bold). Your app would be affected if it uses this public API; you would have to adjust the terms in your code.

The majority of changes is to protected API, i.e. it could only affect you if you derived from framework classes (e.g. for creating custom widgets). Usually the renaming is straightforward, e.g. “Mouse” into “Pointer”, or “Click” into “Tap”. Of course, the qooxdoo migration job is going to list all (possible) names in your code that should be renamed.

Anyway, your existing and future qooxdoo apps will benefit from the input-device independence. The event API should also be quite consistent in terms of naming, so it’d be some pleasure to work with. Take the chance to get your feedback included before we merge the branch into master. The earlier the better, particularly well ahead before we ship the next release. Depending on your feedback and our own ongoing testing, we plan to merge the branch into master within a week’s span.

Bugfixes

For a complete list of tasks accomplished during the last working week, use this bugzilla query.

Have a nice weekend.

Pointer Events

During recent weeks, pointer events have been the dominating topic in the framework team, as we already teasered in the weekly blog post some weeks ago. With this post, we want to give you a deeper insight into this topic.

The Challenge

qooxdoo features three GUI toolkits: desktop, mobile and website. Connected to these domains are the main input devices: mouse for desktop / website and touch for mobile. In detail, this means that desktop / website widgets register mouse event listeners and mobile widgets register touch event listeners. So using one type of app with another input device is at best not optimal. For that reason, we already added emulation layers for mouse on touch devices and touch on PCs. But transforming one event model to another is error prone and simply doesn’t feel natural. Another way to get the optimal user experience would be to listen to both types of event for each widget, but making that change takes a lot of effort without providing an ideal solution.

Pointer to the rescue

Luckily, some clever guys at Microsoft already recognized this issue and came up with a W3C spec named Pointer Events, which tackles this problem. The main idea of this spec is to offer a unified event, independent of the input device. In an ideal world, we would simply use these events and everyone would be happy. But every web developer knows that we don’t live in an ideal world and we have to support browsers that don’t implement the spec. In fact, it’s only IE10+ which already has support for native pointer events.

Pointer Spec in a nutshell

In a nutshell, the spec is based on mouse events and maps all input devices to pointer events. It extends the mouse event type with additional information like the id of the pointer for multi pointer devices. So as a developer familiar with mouse events, you will feel comfortable with pointer events as well because most of the events are equal at first sight, like pointerdown, pointermove or pointerover. For more details, take a look at the spec.

What we already did

Having pointer events in mind, the task was clear: offer pointer events for our GUI toolkits. That means adding event handlers for the website and desktop / mobile layer, bringing these events to the widgets and changing every widget so it listens to pointer events instead of mouse / touch events. After that, change every app we ship with the SDK to use pointer events as well. If we slow down a bit and take a step back, the most important things to consider here are the event layers which fire the pointer events. So here is a listing of the newly added pointer events:

  • pointerover
  • pointerout
  • pointermove
  • pointerdown
  • pointerup
  • pointercancel

If you have the spec in mind, you will see that this list does not contain all events it mentions. But these are the most important events we need for widgets so we kept the list as small as possible. This is one of the reasons we don’t like to call this implementation a polyfill, even if in most areas it’s well-aligned with the spec and is quite broad in scope.
All the events mentioned above have one thing in common: They are atomic. The click event for example is not atomic because it is generated by a sequence of other events. But click is also closely connected to the mouse so to achieve our goal, we needed something input device independent here as well.

Gestures on top

But click is not the only combined event we know. Think of tap, swipe, or rotate in the mobile world. So we introduced another set of new events which can be grouped as gestures:

  • tap
  • longtap
  • swipe
  • rotate
  • pinch
  • track

All these events should work with either mouse or touch. Of course, for rotate and pinch, you need more than one pointer, which is not possible using a mouse.

What’s still missing

There are still some challenges left for us to tackle. One obvious thing is scrolling as there is no mouse wheel or scroll bar on mobile devices. Most of the algorithms relying on hover events are to be refactored e.g. Drag & Drop, quick selection for lists and tooltips. Last but not least, we need to add some manual pages explaining why, how and when to use use these events.

Give it a try

While we continue to complete this event layer, we would like to invite you to take a look at the changes so far. Check out our demo apps we built based on the pointer branch and let us know what you think.