home | xyWrite 3 overview | xyWhat? | PostScript NAQ

Keybored? (Just wait ...)
direct links to two very classy keyboard products:

Datalux Spacesaver keyboard: my Fkeys are better than yours ;) (review below)
Dev-Labs KR keyboard remapper (with text browser): enthusiastically recommended, but know what to expect



[GRAPHIC: Datalux Spacesaver keyboard with
touchpad built in]
You can remap your non-xyW keyboard universally--and economically. Dev-Labs' slick KR shareware keyboard remapper lets you drag and drop from tables of ascii/ansi chars, nonprinting ("special") keys--all of 'em, and macros (combining either or both) to a graphical representation of your win9x keyboard. That's right, all keys: even CapsLk, NumLk, ScrlLk, and PrScr (keys that were out of range in previous releases). KR's kbd editor is straightforward and intuitive and v0.89 makes integrating macros easy. KR answers just about any remapping need this side of Sanskrit or Kanji. If diacrits matter to you, KR does deadkeys. It's designed to facilitate toggling bilingual layouts.

You can combine Shift+Ctrl or Shift+Alt (Ctrl+Alt or Shift+Ctrl+Alt only via macro). KR includes L/R Win and App among its supershift keys, and you can map them even if your physical keyboard omits them. My unusual compact kbd lacks one key, numKeypad Enter; KR gives me one.

I find KR compatible with Total Commander and NoteTab(s), but we are after all on Microsoft turf here, where no day is entirely sunny. KR wants for mouse emulation. (Maybe Dev-Labs has mouse options in mind for KR 1.0?) While the icon KR places in the system tray lets you toggle the remapped kbd off and on, KR sorely needs a command line activate/deactivate switch so users won't have to reach for a pointing device when it's necessary to turn off KR momentarily.

Remember to reach for it before loading xyWin and nbWin. You should not be shocked to learn that if you load either while KR is enabled, keyboard response within the xyWrite-derived Windows app will be unpredictable--dueling keyboards and all that. I use xyWin and nbWin less than I probably would because, alas, KR-remapped win95 convenience is more valuable to me than Signature's Windows progeny are. Not so major a conflict KR must be deactivated, but hotkeys Opera maps to the numeric strip don't work while KR-remapped, nor do the same chars where relocated work as hotkeys. Opera double-assigns many hotkeys but not maximize-window or next-frame, and windows too often open at less than max and the focus always is on the wrong frame.


Anyone who remaps CapsLk, NumLk, and ScrlLk knows what happens when task-switching xyDos under a gui (not just Windows). On my compact kbd, those keys are prominently positioned and beg to be assigned more practical and oft-used funcs or macros. In dos xyWrite, no prob. But task-switching xyDos with win95 apps and a coordinated KR 0.89 map can compound the gui LED key prob: When the going gets too heavy, KR has a tendency to swap maps unexpectedly (CapsLk is somehow involved in the process). Dev-Labs tells me that win95 lets an app disable the LEDs but subsequent Windows releases don't; KR 0.89 comes in one flavor, for win9x. So while KR 0.89 frees those keys for customization, remap them cautiously.
I've moved xyW toggling funcs--just not those marked on the keys--to all three LED keys and have assigned a placebo macro (cursor left/cursor right) to the shift position of those KR keys to tap when the LED is on inappropriately. If you don't need two KR maps, duplicate the first as your alternate map to keep keys from momentarily taking on an apparent life of their own, possibly attempting or--yikes--accomplishing unwanted actions. My experience won't necessarily be yours, however. My notebook and laptop behave differently with the same external physical kbd. xyW3/4 func DX has choked every computer I've used since my XT clone, but other folks use it uneventfully.

I hope I haven't failed to convey KR's absolute indispensability to me. The aggravations cited--trivial compared to the convenience of having funcs on my win95 kbd on the same keys as in my customized xyWrite--have to do more with running a dos app under a gui than with Dev-Labs' invaluable KR keyboard remapper. You don't have to remap LED keys, y'know. At any rate, Dev-Labs gives you a free 30-day full-featured try-out before you must ante up a measly $15.
reviews: Datalux kbd | Dev-Labs KR kbd remapper | <toc>
Some KR tips that probably look more techie than they are
You can build KR macros from the ascii/ansi and nonprinting char tables or--more efficiently and undocumented--write them directly to a KR 0.89 macro file (*.m) with xyWrite (get that ascii 26 eof off the end) or another text editor. E.g.:



Load the KR keyboard editor from the system tray icon. Ctrl+M to the macro editor, and open your *.m file. The editor brings the macros into the keyboard file it generates. Dragging chars and macros to the kbd editor's keyboard template to customize a layout for your needs couldn't be easier. The kbd editor has lost its trashcan, unfortunately, so if you change your mind you now must drag the char or macro you prefer to the template. The process is trivial, but the effect can somewhat inflate the keyboard file (*.k) with otherwise unneeded entries.

xyWrite->KR 0.89

These *.k counterparts of xyW ;KB; files also are ascii. Getting into the *.k files themselves is entirely unnecessary. But if you build xyWrite ;KB; tables you'll probably be tempted to poke around, and the rest of this section compares *.k to ;KB; files. If you edit *.k with xyW, store without eof ascii 26. Again: One need know none of this stuff to configure or use KR.

KR 0.89 *.k tables are simpler than in previous releases' *.kbd files and a resemblance to xyW kbd files has emerged. Where xyWrite uses a separate table for each shift or supershift state. KR puts all assignments for one key in one matrix, and represents chars with codes: A[scii/Ansi]nnn, nonprinting Snnn, M[acro]nnn. (Having a complete S table would be nice, but Dev-Labs really has no reason to provide one.) The editor appends macros to *.k in this form:

Etc. That macro is then mapped as "M1". Keys in *.k usually have familiar numbers, but those numbered => 90 in xyW are >300 in KR, and while keys 87 and 88 have the same numbers in KR, key 84 is also >300 (a few fall just short of 300). *.kds templates are instructive.

In the example below, keys 26 and 27 are, as in a xyW ;KB; file, the keys marked "[" and "]". "nm" = ... uh, let's see ... normal? (unshift and Shift), "lc" = left Ctrl, "la" = left Alt. (You can configure KR Shift, Ctrl, and Alt keys individually left/right or in tandem. Mine work in tandem, so lc or la suffices--no rc or ra entry is needed.) Compare corresponding xyW and KR remapped "[" and "]" keys:






parens( A[scii/Ansi]40
 ) A[scii/Ansi]41
brackets[ A[scii/Ansi]91
 ] A[scii/Ansi]93
guillemets« A[nsi]171
 » A[nsi]187
angle brackets< A[scii/Ansi]60
 > A[scii/Ansi]62
braces{ A[scii/Ansi]123
 } A[scii/Ansi]125


nm=A40 A40 A91 A91 A91 A91
lc=A171 A171 A123 A123
la=A60 A60 A123 A123

nm=A41 A41 A93 A93 A93 A93
lc=A187 A187 A125 A125
la=A62 A62 A125 A125

In case you find that KR is not for you, the Dev-Labs site thoughtfully offers links to the competition.

Insight Software Solutions' Macro Express ($35) offers mouse support and a keystroke recorder and has lots of fans, but it also has a frantic interface that tries too hard to think for you.

GDG Systems' KeyGO ($79) resembles KR. The last time I checked, in addition to the compound tables KR permits, KeyGO allowed Ctrl+Alt tables, but CapsLk and PrScr and L/R Win and App keys were out of range, kbd files were binary, and analysis of its operation was impossible. Although the hype said the downloadable demo gave you 50 free keystrokes I could get only one.
I tested a keyboard mouse that's a secondary feature of KR-compatible ToggleMouse, a utility that does a lot of nifty hardware mouse tricks that justify the price but aren't much use to me because software bundled with my touchpad does the niftiest of them. Lamentably, TM hard-codes kbd mouse key assignments; you only get a choice of layouts. The best hard-codes both sets of cursor keys, overrides CUA Ctrl+A (block-all) with left-click (duh), and offers no diagonal movement options. TM kbd mouse reduces reaching for a pointing device a lot, but not all. When the trial period ended I decided not to invest in the utility, but I'll definitely keep my eye on future releases in hope it matures a bit. Also, Dev-Labs has promised a new release, and who knows ... I came across a tiny, simple, dedicated keyboard mouse that also seems to be compatible with KR and also doesn't involve mickey mouse constant toggling with NumLk, etc. But the downloadable demo is disabled literally every 20 minutes, making uninterrupted evaluation impossible (and the presence of two mystery features annoying; "documentation" obsesses about payment, usage be damned). Yet (win9x/NT) KeyMouse's price is the same as that of the richly-featured text editor NoteTabPro (and of the last hardware mouse I bought), more than half that of ad-free Opera, a full browser, and more than that of the far more complex KR. Dunno why developers even bother publishing severely limited demos--or why the same developers are inclined to overprice their software.
Dev-Labs KR kbd remapper review | <toc>

    Every PC-armed obsessive is itching to rant about a fave keyboard.
    I've resisted long enough. Let me tell you about mine.

No conventional keyboard can come close to the Datalux Spacesaver's efficiency as a writing and editing tool. Period. But for many people a particular touch is the sole keyboard priority. If you're one of them, whatever Datalux's virtues, it probably isn't for you; more on that presently.

This is a keyboard designed by one very smart man, not a computer industry board. The design radiates intelligence. Except for LED keys, KR and xyWrite make what a manufacturer maps to individual keys irrelevant, but the way the manufacturer clusters keys and places the keypads is very important indeed. The Datalux arrangement of component keypads is particularly thoughtful.

Heaven knows Fkeys strung out in one row are the work of the devil, but the Datalux design disproves the claim that God meant Fkeys to be a 2x6 clump left of the alphanumerics. Using a Datalux kbd will quickly persuade you that She meant them to be clumped 4x3, aligned left with and above the alphanumerics. Balancing the Fkeys, aligned right with the alphanumerics and above them, is the conventional cursor/numeric keypad.

Let me respectfully suggest that this review
		is more meaningful with graphics on (small photos) Adjacent to the Fkeys at right are redundant Ins and Del keys that xyWrite and the KR remapper let you redefine as Alt and Ctrl. A third key at right, marked Esc, ideally would be Shift, but another need trumps that.
     Think about it. Those keypads are thus literally at your fingertips, not a lateral move away. Uncurl the fingers of either hand and fingertips settle across another four-key row as naturally as they normally sit on ASDF JKL;. Muscle memory draws them back effortlessly to the home row.

About the only good idea the Datalux's designer hasn't integrated is bundling the KR remapper:

Between the cursor/num and Fkeypads at top center are the redundant cursor keys plus Pause in a symmetrical 3x3 clump that demands remapping as a numeric keypad to free the unshifted main numeric strip. Yeah, nine keys ... a numeric keypad without zero? The only key that nominates itself is in right-thumb relationship to the neonumeric keypad--the key marked Esc. Groan. There went Fkey Shift. (I map the cursor keypad 5 as Esc.)

Of course those keys can be used as marked, with NumLk routinely turned on to justify their existence. But reaching up and right rather than center for cursor keys seems natural, and I use the outside right keys too for navigation. (I should probably mention the primary goal of my mapping strategy: to place as many most-used chars, funcs, and macros as possible on unshifted keys with no duplication.) For anyone who doesn't mind old-fashioned dual-purpose cursor/numeric keys and doesn't burn to remap the extra cursor keys, a pricier model cleverly replaces the extra cursor keys with a touchpad.

It should go without saying that CapsLk and Left Ctrl are where they belong. NumLk and ScrlLk are prominently placed, immediately below the Fkeys. In dos they're great for high-profile funcs (Esc, e.g.), but the LEDs then become a real prob when task switching under Windows. The touchpad model's Pause key is moved next to them (photos do lie; look at the touchpad model schematic linked to these photos).

Oh. Did I mention that the footprint is uniquely modest--no deeper than a conventional keyboard, the width of a normal alphanumeric keypad? After using a Datalux, conventional kbd sprawl seems like an act of aggression. The stretch between Datalux rows is reduced so slightly I've never noticed--and I do notice notebook keyboard size compromises because even the best cramp key width; Datalux does not. When I have to use a conventional kbd I have no adjustment moment with the alphanumerics (I can't say the same of the rest of the keys spread haphazardly all over the desk). Datalux does short remappers two keys. The numKeypad Enter is physically absent. Thanks to KR, my win95 Shift Enter is numEnter (some apps--QuarkXPress, e.g.--distinguish between Enter keys). And the numKeypad * and PrtSc, on separate keys at the right corners, somehow are wired so, if remapped in xyWrite or win95, the two must be assigned the same char(s).

For xyWriters who still use default mapping, the Fkeys that happen to fall outside left are F1, F5, and F9(!). This will sound a bit off the wall, but the top outside keypads are so balanced that in dos, xyWin, and nbWin you could conceivably flop them and map the Fkeypad as cursor keys and the cursor/numeric keypad as Fkeys. (I've used systems that did have cursor keys left, and one reason a user might want to flop keypads is unilateral r.s.i.) Some Windows app mapping overrides KR's, however.

Touch is stiffer than most of us probably prefer. One adjusts. Datalux also offers an "industrial" version for field use; I gather that what makes it different is that it requires you to really pound on keys. The characteristic seemed odd in view of what was the lone more serious flaw in the past, but may no longer be. The warranty is only one year for a reason that used to become obvious all too soon. Although workmanship is unassailable, keys of Spacesavers manufactured from the early to mid-'90s started sticking way sooner than they should have for the price, which then was considerably higher than the last quote I saw, on www $84 (redundant cursor keys; FOB Virginia, where the keyboards are manufactured). My first Datalux kbd cost, as I recall, $130. Happily, the Spacesaver I've used constantly for well over a year (30 August 2001) shows no sign of sticking keys. Perhaps specs for the striking mechanism is more rigorous these days? (Stay tuned.) Improved quality at a lower price--what's not to like? (Update, 6 June 2003: still no sticking keys. As far as I'm concerned, that's become a nonissue. The bad news now is that the price seems to have risen to $105.) (Update, 17 November 2004: Neglected to note current price, but the connection is now USB with supplied ps/2 adapter. The earlier ps/2 keyboard works with a ps/2-USB adapter--even with an iBook, although of course with no way to map Mac supershift keys, at least not withoutthe overpriced CE QuicKeys util.)

Each model--extra cursor keys or touchpad--is offered in a choice of housing and in charcoal or light gray. If you attend computer trade shows, look for Datalux kbds (these photos don't do them justice) set up for public input at a few exhibitors' kiosks, often with Datalux flat-panel screens. I've also seen them in mail order catalogs but never in a store. The apparent business plan is B-to-B, but the manufacturer gladly sells individual units via www or direct.

The flat-tray version's lightness and Spartan geometric form make it more portable. Mine, propped up at the back, spans my laptop's built-in keyboard (same width), still leaving the laptop's trackball available.

The classic desktop Datalux keyboard (same price) slopes at an angle that looks to me like an invitation to the unwary to give r.s.i. a chance (I had it pre-Datalux and I know how to make mine stay away); I suggest using a wrist rest with this baby. That said, this model causes me to wonder if Robert H. Twyford, the mechanical engineer who designed it, in a former life was a celebrated naval architect. The housing is a contoured case whose shape is as winsomely sensuous as a scale model of a yar sailing vessel. Not inappropriate for hardware a user has a peculiarly intimate relationship with, certainly more than with any other PC peripheral. The Datalux keyboard line's key layout exemplifies the same design imperatives as a well-considered sailboat cabin.

The desktop model deserves to be in museum design collections. The compact design joins engineering skill and industrial creativity with a strikingly graceful aesthetic. Perhaps the flat-tray touchpad model belongs there too. Of its kind it's the epitome of form following function--the ultissimo in uncompromising touch-typeable all-day-everyday input-device space economy.
Many years after buying my first Datalux keyboard--never mind what a singularly efficient tool it's been--just looking at its sculpted lines still pleases my eye. How many keyboards can you say that about? This review is more meaningful with
		(not very big) photos of the kbd visible

Should you end up owning both KR and a Datalux kbd, I'll cheerfully email you a Datalux template I wrote for the KR kbd editor that saves you from having to interpolate from a blank conventional kbd.

reviews: Datalux kbd | Dev-Labs KR kbd remapper ||| home | xyWrite 3 overview | xyWhat? | PostScript NAQ

adpFisher nyc 17 november 2004