Daniel Elstner wrote:

However, I think he's wrong in picking on GTK+ as the culprit for some
of the UI annoyances.  For instance, I don't think it's true that GTK+
only deals with simple input one character at a time.  I'm pretty sure
it's possible to pull off Newton-style handwriting as described by him
with a sufficiently sophisticated GTK+ input module.

I'd be glad to modify the article (and have) in response to corrections, and actually HWR is rather low on my list of complaints in the article. But no, the Newton's facilities, so far as I can tell, cannot be reasonably replicated with a plug-in input module, except for providing better recognition perhaps. But I'm not losing sleep over it. Though GTK is a classic least-common-denominator framework, it does allow lots of apps to be ported to the N800 immediately, and that's a worthy tradeoff. My article tried to focus on things they _could_ change without performing open heart surgery on a large open-source framework. HWR was low on the list.

The Newton's HWR has three relevant characteristics for discussion here:

1. Interpreted handwriting is rarely handled by the underlying application through the event system, much less through a keystroke event facility; and in fact an application typically doesn't know or care that text is being written in one of its fields. It just shows up. You *can* override this facility to shove text at an application through key events (Newtons have keyboards) but it's not the default mechanism. An app could also receive text in whole paragraphs if it liked, and that text could include embedded pictures and intentionally uninterpreted handwriting in the form of stroke sequences (they're called "rich strings").

2. Handwriting happens directly in text fields and text areas, not in a separate pop-up region.

3. The recognition is sophisticated.

#3 is doable on the Nokia with a replacement module. And of course #1 and #2 be done inside an application with a writer who is sufficiently talented (or demented). But it's besides the point. For #1 and #2, the other applications won't _automatically_ use that app writer's handiwork, because GTK's framework [probably] doesn't support it. Each app would have to code for and link against his new library. But the whole _point_ of a GUI is to provide *all* applications with a powerful and consistent framework so they don't have to do tons of work writing their own (different from one another) approaches to user experience.

Note: I wrote [probably] because as best I can tell GTK apps, like most UI systems originally created on PCs, routes text in the form of key events. But I'm not positive about this and wouldn't mind being corrected.

Note 2: if you're interested in the Newton's UI and recognition system as a developer, you might look at http://www.unna.org/unna/ apple/documentation/developer/ProgrammersGuideOS2.0.pdf
The chapters of interest are 8, 9, and 10.

Sean

_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Reply via email to