From: Paul Rohr (paul@abisource.com)
Date: Wed Apr 24 2002 - 03:02:26 EDT
At 11:38 PM 4/23/02 -0400, Havoc Pennington wrote:
>I would postulate:
> - it should work just like the Delete key on the target platform
>
>So if on Windows XP or GTK+, the delete key blows away the whole
>combined cluster, then undo should also treat them as a unit. If
>not, then undo should not.
Thanks for the suggestion. The "undo == platform-specific backspace"
principle is admirably simple and easy to understand. However...
1. I'm not sure this principle helps.
--------------------------------------
We currently control the semantics of the delete and backspace keys in XP
code. (In fact, that's what we're debating on the selections thread, IIRC.)
How would we fall back to some platform-specific notion of delete semantics
here? More to the point: why should we?
I *like* the idea that you don't necessarily have to know what platform
you're on in order to type "properly" in AbiWord. That way, we're defining
the "word processor" semantics of typing large amounts of text.
I'm leery of letting that user experience vary on a platform-specific basis.
After all, it's not like MSWord confines their user experience to what the
RichEdit32 control supports. ;-)
2. I'm not sure it's right.
----------------------------
Given the ways Jeff wound up tuning our existing Undo coalescing behaviors,
I'm not at all convinced that Backspace and Undo should always have the
exact same semantics. It may sound good in theory, but you really have to
see how it feels in real life.
For example, one way to transform a fairly convenient infinite undo feature
into a major headache is to turn off all of Jeff's change-record coalescing
tweaks and *force* you to march back through every individual character you
typed. Trust me, it's miserable.
Jeff never was totally happy with certain subtle details of the final
result, but the net effect is much, much better than no coalescing at all.
3. My half-baked intuition.
----------------------------
As I tried to suggest elsewhere in this thread, I have a general intuition
that, if anything, we may want undo to glob at a *less* granular level than
selections.
Of course, that would in turn depend on how granular the selections are,
which is why I tried to lay out some specific screw cases from the W3C
document Karl found for us:
http://www.abisource.com/mailinglists/abiword-dev/02/Apr/0721.html
The nice thing about screw cases is they allow everyone to understand how
various proposed rules actually work in practice.
4. My half-baked idea of where Andrew's coming from.
-----------------------------------------------------
For the sake of completeness, I should mention that Andrew's intuition seems
to be tugging him in both directions:
http://www.abisource.com/mailinglists/abiword-dev/02/Apr/0730.html
For example A2, he'd have:
- three keystrokes (one a deadkey)
- two characters inserted
- two backspaceable, selectable characters
- two undo operations
For example A3, he'd have:
- nine romanji keystrokes (in the IME)
- three kangi characters inserted (as a single insert)
- three backspace-able, selectable characters
- one undo operation
Whereas for example A4, he'd have:
- five keystrokes
- six characters inserted (in five steps)
- six backspaceable, selectable characters
- five undo operations
Or at least I think that's what he means. As anyone familiar with the
EV_Keyboard <--> EditMethod codepath knows, the notion of a "user keypress"
is kept deliberately hidden from the undo mechanism. The piece table just
cares that one or more characters got added, deleted, or formatted at a
given offset in the document.
So far, these examples all sound consistent with my intuition.
Yet later in the same post, when it comes to Vietnamese -- he doesn't
discuss the Tamil example -- well, I get lost. I think in this case he
wants coarser selections, and finer undo.
5. Where Andrew and I get confused?
------------------------------------
I *think* the net effect is that due to a historical artifact, Andrew's
notion of "keystrokes" blurs into the mechanics of the actual characters
encoded.
Call me incredibly naive, but I'm concerned about a user experience which
makes cases A2 and A5 look and feel the same for selection purposes --
presuming we go with stacked or cluster boundaries -- but different for undo
purposes.
In short, in both cases, as far as the user's concerned, isn't the simplest
mental model that they just have two kinds of keystrokes:
- ones that directly add characters, and
- ones that decorate other characters?
The net effect is that they may have to type some "extra" keystrokes to
assemble the exact character glyphs they want. However, it's not at all
clear why the undo semantics for A2 and A5 should thus be any different.
Why should an AbiWord user's mental model have to reflect distinctions such
as:
- deadkeys,
- precombined characters, and
- combining characters?
Is there a user-visible difference worth capturing here -- for example, how
it feels to type (or select) each of the examples? If so, what is it, and
how does it work?
Or are we just creating a user experience that mirrors the underlying
mechanics of the character encoding? If so, that may be easier to program,
but it feels we've gotten the design backwards. Where feasible, I'd rather
have us paper over any lingering encoding artifacts in favor of a consistent
typing and editing experience.
But then again, I've never typed in most of the languages in question, so
what do I know?
Paul
This archive was generated by hypermail 2.1.4 : Wed Apr 24 2002 - 03:03:07 EDT