1.34 key relocate feature, rats!

[declarke]

hmmm. after carefully figuring out how many mm to move each
keycap in x and y to maintain a nice equispaced, scaled-down
layout, I am greatly disappointed to find that there's no
numerical offset feedback in the GE when the keys are dragged
around. you can't tell how far the key has been dragged!

moreover, the xml output for a relocated key appears to specify
absolute rather than relative location, so I can't even edit
the xml to make a precise adjustment of all the key positions
on both pads. the key loc xml is only emitted if the key has
been moved so there is no way to get the factory default
position.

the non-quantitative dragging method is simply too imprecise to
make a good symmetrical layout, imho. how hard would it have
been to provide a little "drag gauge" in decimal x,y
millimetres that pops up when the key is being dragged? that
would have been sufficient. grmph.

btw, the ability to group-select more than one key at a time
for dragging would also save a *lot* of drudgery.

well, so much for my motivation to upgrade to 1.34 -- the
relocatable keys feature was what inspired me to go through
the upgrade experience, and now it turns out to be implemented
in a way that's not useful (for me) ... sigh. all that fuss
for nothin'.

I guess I could do this properly if FW would give me the
default x,y positions of all the keys. then I could apply my
calculated offsets and hand-craft the xml. how about it?
it would be tedious, but do-able.

de (the short-fingered)

[fingerworks]

We can see about adding a 'drag gauge' in the future. It would be nice to have the adjustment specified as an offset from default in the config file--probably we will change to that format when we implement automatic adaptation of key locations.

However, you're probably overstating the need for numerical precision when adjusting the key locations.

You may THINK it's important that each key be spaced perfectly to fractional millimeter precision on a regular grid. However, I assure you that in practice, only distinctions (or changes) of at least 1-2mm will have any signficant affect on your typing accuracy. And changes of say 2mm are easy to eyeball with the GUI as approximately half the distance you can drag a key.

In other words, some of you may feel more confident working with the raw numbers, e.g. coordinates, but in the end the regularity or numerical precision of your key grid is not what really matters. What matters is whether you've correctly identified the keys that are affecting your error rate and moved them far enough to compensate for your under-reaches.

[declarke]

Originally posted by fingerworks

You may THINK it's important that each key be spaced perfectly to fractional millimeter precision on a regular grid. However, I assure you that in practice, only distinctions (or changes) of at least 1-2mm will have any signficant affect on your typing accuracy. And changes of say 2mm are easy to eyeball with the GUI as approximately half the distance you can drag a key.


but I plan to be dragging just about every key, so the original grid will be lost pretty quickly. it's hard to eyeball a layout when nothing stays in its original place -- there's no reference left. you can get confused/lost real fast. I really would rather not try to do a compression/rescale of the grid by eye and tedious mousing.

so ummm do I take this FW answer as a refusal to disclose the default key locations? <grin> fine, whatever; how about the answer to just one simple question -- is my LP a "straight stealth" or a "slanted stealth"?

my guess is that it is a "straight stealth", because the keymatrix version 33 in

<MTS_config MTS_config_version="1.3.4" min_firmware_version="1.1.7"
product_class="stealth qwerak dvorak"
copyright="Copyright (C) 1999-2003 FingerWorks, Inc. All Rights Reserved."
keymatrix_version="33">

(file FW_straight_stealth_keys.xml) seems to correspond to the 33 in the filename

custom4f0040stealth33.U.byt

and that makes me think that what I have is the straight-stealth model.

if you could just confirm this, then I fancy I'm well on my way to scaling down the key grid.

de

[fingerworks]

Yes, key matrix #33 corresponds to FW_straight_stealth_keys.xml.

[declarke]

Originally posted by fingerworks
Yes, key matrix #33 corresponds to FW_straight_stealth_keys.xml.

that's not what I asked . . . I know that (what FW writes above) because the matrix 33 specification is in the xml file of that name. what I was trying to confirm was that the "33" in the binary file name

custom4f0040stealth33.U.byt

corresponds to the key matrix number.

guess I'll just assume that it does and hope for the best.

de

[fingerworks]

Yes, that too.

[declarke]

I note that for some TapAreas, the radius is specified; but mostly it isn't. this suggests that there may be a default TapArea radius.

The small scattering of explicitly specified radii makes it hard to guess what the default might be. I thought at first it should be 1.0 and that the deviations were expressed as a scale. But then I came across some keys whose radius or xradius was 1.0 . . .

Question for FW: what's the default radius? are the radii expressed in cm or scale factors of some hardwired constant? (where's the dtd?)

The xcenter and ycenter values I am guessing are in cm in some ideal coord system. Yes?

The rotation values for R and L pad are interesting -- the values are -1 and 1. degrees seem like too small a unit, radians I suppose are possible given the "relaxed" position of the TS on a flat surface.

I was relieved to see rotation specified as it implies -- I think -- that I can work in plain x.y for key offsetting instead of having to calculate rotation.

Hmmm, I have a feeling I know what a chunk of this weekend will be spent on :)

if anyone else is interested in this xml exploration, feel free to join in! multiple flashlights illuminate plato's cave much faster than just one.

[fingerworks]

default radius is 1.0, everything is in cm except rotation is in degrees, with respect to (0,0). One question though--you CAN see the nice blue circles we draw for adjusted keys over the default yellow circles, right? Still not sure why using the GUI would not be easier. Just admit it--you LIKE hacking XML!

[declarke]

Originally posted by fingerworks
default radius is 1.0, everything is in cm except angles are in degrees.

thanks for the clue.

hmm the rot angle does seem very small... is the coord sys drawn with the 2 pads flat and touching side by side, then, w/o the cable installed? if so then the small rot angles would be a teeny tuning tweak. in that case I'm not sure of the rotation polarity -- I was thinking pos = CW and neg = CCW but if it is only 1 degree then who knows. (the FW gang do!)

if I'm understanding the implications of this file correctly, then we TS owners can -- by editing a suitable chunk of xml into a file and then "merging" or "adding" this to our existing config -- rearrange the key strike areas, resize them, etc, in very radical ways. fascinating. scary :)

de

[declarke]

Originally posted by fingerworks
d One question though--you CAN see the nice blue circles we draw for adjusted keys over the default yellow circles, right? Still not sure why using the GUI would not be easier. Just admit it--you LIKE hacking XML!

I can see the nice blue circles, though they blink disconcertingly at times. but I want to relocate keys by further than 5mm, and to change the key radius where I'm getting too many accidental hits. and to accentuate the curvature of the baseline, and . . . the GUI is just ducky for tweaking one or two problem keys, but I have a beef with the entire scale and baselines of the grid. not to diss the GUI which shows a lot of thought and nice features, but imho it isn't useful for such a fundamental key shuffle.

my goal is to find a way of scaling the whole layout down to where I'm not having to do any gross finger excursions during normal typing. the punct pad helps but it's not enough -- the num row is an awkward reach and so are the outliers on the R hand.

in an ideal world I never lift my palms off the rests, there are no awkward reaches, and keys are where I expect them to be. discovery of the TapArea xml elements is like finding out that your shoes can be easily adjusted to stop giving you blisters! I can FIX this keyboard! it really is a Gumby keyboard as I always wished it would be, instead of being wired forever to the hand size of a college basketball star. (OK I exaggerate for effect, but you get my drift).

actually I'm kinda new to xml, but old and canny in coord sys mapping and code parsing/generation. would infinitely rather write an app that generates xml -- and regenerates it cleanly as I tweak (using CODE) good honest numbers in a coord system I understand -- than sit there dragging little widgets around over and over again, having to hand-adjust every single one if I change my mind -- believe me! this is a hacker's keyboard and I'm a hacker -- you surely don't expect me to be content with a GUI that limits my options (and sometimes even gets into inconsistent states) now do you? :D not when I've just seen the door open a crack to creating my own layout, customised for my own hands and my own typing eccentricities!

btw a mode where the x,y location of the user's finger strikes is reported in real time would be immensely useful for customising. I'd like to trigger such a mode with one of those arcane whole-palm swipe gestures -- or something 2 handed and not easy to do by accident -- so I wouldn't have to relaunch the MTU app to switch modes.

you wouldn't be able to cook up a beta rom binary with the "spit out user tap coordinates" mode in it, just as a favour, by any chance? failing that I'm gonna have to make exact-scale printed overlays and ink my fingertips, or stunts like that, to try to digitise the natural finger strike locations.

de