I've managed to mix up the QwikScript input method for Qtopia with the Hildon input method plugin example. The result is an input method plug-in implementing QwikScript on the Maemo OS 2008 platform.

The code is available in the garage (project name: qwikscript). It's currently in beta form: it works, I haven't have it crash on me yet, but it's still not 100% perfect or feature complete.

I've only made a .deb available for now; you'll need to sudo gainroot to install it.
EDIT: you'll also need to restart your tablet, at least until I figure out how the input method process can be restarted.

Note that the code is still somewhat rough; I'm releasing it in the hope that others will find it as useful as I do right now. Namely, the input area graphics are not to my liking, and the virtual keyboard's shift/modea/modeb keys are ignored.

Let me know what you think, but please be gentle, it's my first Maemo application.

What is QwikScript?

The QwikScript input method was originally written by David Placek and is inspired from Ken Perlin's "QuikWriting" input method. It's a bit hard to explain without some sort of screenshot. Look for it in the attachments to the post.

The two square areas with a center circle are the alphabetical and numeric input areas, respectively.

There are two sets of characters per area: outer and inner. The inner letters are accessed by inputting the "square" character as a prefix.

To enter characters:

Move the pen to the center circle of the desired input area;

Find which region (separated by gray blotches) contains the character you want;

Move the pen to that region;

Depending on the position of the character in the region you are in, move the pen to the region towards which the character points to. For instance, the rightmost character in the upper-left ("K") region points to the upper-right region.

Move the pen back to the center circle.

This sounds complicated, but it's actually quite intuitive once you get the hang of it. To help out, here's an example: to type "abw", you'd do the following movements, starting from the center:

Move to upper-left corner;

Move back to the center;

Move to the lower-right corner;

Move to the low center region;

Move back to the center;

Move to the lower-left corner;

Move to the left center region;

Move back to the center.

Here's an explanation of the different symbols in the input areas, besides the obvious ones:

Square: switch to "inner" characters in the area. Valid for one character.

Triangle pointing up: shift (characters are normally lowercase). This is good for only one character as well.

Triangle pointing left: backspace

Triangle pointing right: space

Circle with a dot in the center: swap the two input areas for one character.

Well, I guess that pretty much sums it up. Post any comments/complaints/praises here.

Attached Images

Last edited by bge; 2008-05-08 at 02:14.
Reason: Moved screenshot to attachment to offload Garage a bit

Thanks so much; I think this is the first 3rd-party input method, so you're definitely a trail-blazer here; I think I'd rather have a graffiti-ish system (less learning), but I'm certainly going to give this a shot.

I'm going to try it in portrait mode, as I'm reasonably happy with the stylus-board and/or finger-board for landscape. HWR is the only input method that retains its utility well in portrait mode ATM, but because it's so bad to start with, it's about tied with the (severely degraded) stylus-board.

So you'll get feedback within about a day or two on that; though it's not horribly representative of mainstream usage, I have high hopes for this.

Edit: Installed fine; not showing up in list yet. (Probably needs a restart...)

I'm going to try it in portrait mode, as I'm reasonably happy with the stylus-board and/or finger-board for landscape. HWR is the only input method that retains its utility well in portrait mode ATM, but because it's so bad to start with, it's about tied with the (severely degraded) stylus-board.

Hmm, hadn't thought of portrait mode at all I'm afraid... I'm sure it won't work, unfortunately, because the coordinates are still pretty much hardcoded everywhere in the code. I'll try to fix this tonight and make a new release. That will force me to clean up all those hardcoded numbers... (and that'll teach me for using them in the first place--in my defense, the original code was full of them, but I should have known better )

As for Graffiti, I beleive the original one is patent-encumbered. Graffiti 2 (Jot) may be OK, but I'd hate to try to code it from scratch... if anybody knows of some open-source code I could use, I'm willing to give it a shot at some point.

Still, by all means, try it out in landscape to see if you can get the hang of it. The port to portrait mode should be easy enough, it's just hard for me to test it. Anybody know how to do this on scratchbox? (I'm not really willing to reflash to test this)

Edit: yes, you need a restart, or at the very least, restart of the hildon-input-method process (I haven't found documentation on how to do a "warm start" yet). When installed, it shows up as "QwikScript" in the input menu.

Rebooted; it works, sorta. One of the two pads is ~75% on-screen with the navigator on the left (or right); with the navigator on the top (or bottom), or in full-screen, 1 pad is on, and the other is about 35% on.

So it's usable, if you have a sane configuration and don't mind using one pad. I'd rather use both; but the functionality's there.

Unfortunately, I think it's too wide to ever fit both pads on with the navigator on the side. I'll post a couple screenies momentarily to demonstrate what I'm talking about.

(Dug up an old post of mine; perhaps I'm one of few who really wanted this...)

The most promising one looks like xscribble, that's graffiti-like stuff. It's also got a website last updated in 2003, and a version number >1 (1.3), so mixed news.

I've only used it a bit, but it seems to be rather finicky about down-right and down-left (switch pads and return) -- it seems as though if I drag too far down before hooking over, it doesn't take it, but if I make a near-circular loop through the correct intersections, that works... Could it be losing track at the bottom edge of the screen? (Or could my screen not be reporting things well at the extreme edge, perhaps...)

As far as the "finicky" part in the bottom: I don't know, I haven't really noticed this (I have more problems with the top-center part myself--I suspect once I add the color pixel detection back from the old code, it will work better). But you don't need to go all the way to the edge of the input area to input characters, even those on the outer edge. I don't go much further than 50% of the way between the circle and the edge myself.