Touchkit scope


I’m playing around a little with the touchkit-agpl stuff from svn in conjunction with vaadin 7. When I integrate it, my vaadin application is always complaining on startup when I use firefox (with an alert box saying you use an gecko rendering engine but you must have applewebkit).

Well, this is alpha stuff. But is this to stay? Will it be possible to integrate with touchkit and serve to desktop browser nevertheless? Or will the touchkit integration rule that out completly? And if the latter what is the pattern to implement the mobile/tablet/desktop switch from within vaadin?


Hi Thomas,

By default TouchKit targets only webkit browsers (and in the latest snapshots mobile ie, although I’m not sure whether these are public yet), and as such GWT complains that there is no version of the widgetset compiled with the Gecko target. Currently there is no plan to support gecko browsers by default in touchkit, but to compile a gecko version of the widgetset all you have to do is remove the

	<set-property name="user.agent" value="safari" />

line from the widgetset module definition (.gwt.xml) and the widgetset compiler should compile the widgetset for all targets. See
Defining a Widgetset
for a bit more information on the topic.



You could check out stuff here:

Especially Servlet and UIProvider. You’ll learn how to select another UI for non webkit browsers (with a different widget set). We have plans and some preliminary work done to extend browser support for TouchKit, but it will take some time. First 3.X version is about to have just webkit based browser support like in TouchKit 2.X series.

During development I highly suggest to use webkit based browsers like Safari or Chrome as they are quite close relatives to most common mobile browsers. Even
Opera nowadays
, now daydreaming of IE to switch its rendering engine…

Currently, if your are planning to a good mobile app, I can’t really suggest to go with the V7 compatible branch of the TouchKit. We still have some serious
performance issues
, especially on the client side. Until those are resolved I’d suggest to go with the V6 version, which is much more stable and faster. We of course try to resolve these issues soon, but due to our bad record on keeping schedules - I wont give any estimates.