MilliKeys is released under the terms of the GNU General Public Licence, with additional conditions listed in Licence.txt.
This project implements a virtual keyboard on the
silkscreen area of a PalmOS device. It supports multiple key
layouts editable on the handheld itself; previewing on the
screen; and macros to start programs or input keys. A 10x4 Qwerty
layout is built-in.
Install both MilliKeys.prc and MKeyHack.prc. You also need an extension manager (not currently included) such as HackMaster or X-Master in order to enable the MilliKeys hack, that is, to use the nongraphic area of your screen as a keyboard. You can, however, try it out without an extension manager by tapping "Test" in the MilliKeys configuration program.
If you have downloaded the source code distribution, please download the binary distribution as well to get the Qwerty keyboard "stamp", which you can print out and glue/tape/laminate onto your Palm. It's really tough to use the keyboard without seeing where the keys are... I should know; my printer doesn't work, and the first version was released before I had a stamp of my own!
If you don't have the source code and want it, go to the MilliKeys project page at http://sourceforge.net/projects/millikeys/
It's a funny thing... I have one of those full-size fold-out keyboards for my Palm IIIxe, but I still wrote this program. Turned out I couldn't just whip out the fold-out to jot a quick note or appointment; MilliKeys fills that gap. Plus, my pockets were already full before I got the keyboard...
Important note for upgrading users: You must disable the hack before HotSyncing. Also, be sure to install both PRC files.
At long last I've finished the new version. I quit working on MilliKeys four months ago due to excessive work load and imperfect health. Both of these will probably return as the new semester progresses, but here's a new version before things get heavy. I know there's a couple of bugs left, but I've decided to upgrade the program to 'beta' status.
An oversight in the Makefile prevented the "Release" build flags from being used on the hack. As a result, at least one user had this assertion failure (the assertion in question did not indicate a bug in MilliKeys; you see, I was wondering whether SysCurAppDatabase always returned 'appl' as the type of the running program, so I had an assertion to check it. The failure indicates that for this particular user, an app he was running was not of type 'appl'. This would not have been a problem had I been using the correct build flags.) To my surprise, once the correct flags were in place, the hack dropped to less than half its original size. It now sits at 9 KB.
Important note for upgrading users: The database format has changed, and the new version cannot read the database from the old version; furthermore, there is a bug which causes it to crash on exit if an old database is present. Therefore, before installing the vew version you MUST delete the old version, which causes the database to be deleted. If you have created a layout you want to keep, export it to a memo before deleting MilliKeys.
Luckily, there are only about three users (yeah, including me) so far, so this problem is not what I would call a big deal.
Also, when upgrading, remember to disable the hack before HotSyncing, and be sure to install both PRC files.
These programs help Visual C++ interpret the output of GCC in its "Output" window. GCCFilter translates error messages to a format VC++ understands (so you can press F4 to step through the errors), while NoStdErr is needed for Win9X users to redirect stderr to stdout. Without NoStdErr, GCCFilter does not receive the output of stderr. But of course, stderr is precicely what GCCFilter is supposed to process (i.e. error messages), hence the need for NoStdErr. On the command line, run GCCFilter -? and NoStdErr (no arguments) for more information. To use them with VC++, put both of these programs in your path for executable files (Tools | Options | Directories | (for) Executable Files). I personally put them in my Cygwin/bin directory.
I had a heck of a time trying to make MilliKeys into a hack.
To begin with, I don't know how to put the application part of MilliKeys--the part you run from the launcher--into the same PRC file as the hack part of MilliKeys.
I have been trying instead to get the hack to coexist with the application in a different database, MKeyHack.prc. I couldn't get them both on the emulator with the same creator ID (loading one would cause deletion of the other, or so it seemed), so I tried giving them different IDs. While that turned out to be difficult in itself (because they share the same makefile and source code), once I had done it (hack ID=MKHk), it still didn't work. I was puzzled, but then figured out that the program title had to be different too. Anyway, with both the creator ID and the titles different, the hack wouldn't activate in X-Master... I determined that it was missing its TRAP resource for some reason, even though it was specified in the resource file AND the source file.
Now at that point I was compiling the resources for both the app and the hack in the source code folder. This was wasteful because the hack inherited the resources (*.bin) left over from the app's compilation, but I didn't mind an increased PRC size when I was merely trying to get it to work. Well, it seems that somehow, resources of other types from the app were preventing the TRAP resource from getting in the PRC. I found that if I deleted tAIB03e8.bin (app icon resource, ID 1000), just before calling build-prc, then the trap resource (also ID 1000) was then put in the prc, and the hack could be activated in X-Master. I didn't think resources of different types could conflict, but since it appears they can, I wonder what possessed the guy who wrote HackMaster to require a trap ID of 1000, when 1000 was already taken by the app icon resource? I mean, I know hacks weren't intended to show up in the launcher when HackMaster first came out, but it isn't too hard to see that someone, someday, might want to.
Anyway, then it occurred to me that maybe the titles
conflicting was the only real problem, but having the same
creator ID was actually okay. So I changed the creator ID of the
hack back to that of the app (MKey) and the apps still coexisted!
This is good news for two reasons:
1. I don't need to juggle two IDs... for example the hack doesn't
have to keep track of the app's ID in order to access its
database.
2. In the 'Delete' dialog on the palm, both the hack and the app
are grouped together into one entry so you can delete them
together. Interestingly, the delete box chooses to label them
collectively "MilliKeys" and not "MilliKeys
Hack", indicating it prefers to use the name of the app over
the hack. This makes sense, though, since the OS recognizes the
app as an app, and doesn't understand what a "HACK" is.
It makes me wonder why Palm bothers to have a creator ID registry, when they lack a database name registry. As far as I can tell, if two databases have the same name, they can't coexist on the same machine. Meanwhile, at least if two databases have the same creator ID, they can still coexist if their types are different. Seems much more likely to me that any two given developers might be uneducated enough to put their settings in a database called "Setup", than that they would choose the same creator ID....
MilliKeys comes in two parts:
Normally you install both of them on the handheld. If you don't install MKeyHack.prc, you won't be able to use the hack functionality (so you're limited to using it in the Test screen). If you don't install MilliKeys.prc, you can't configure the hack. That's okay, though, if you have a .pdb file with the configuration you want stored in it. Just install that pdb and you'll be able to use MKeyHack.prc without MilliKeys.prc, but of course you won't be able to change the setup.
If you do not install a MilliKeys pdb file explicitly, then you must run the MilliKeys setup program at least once before you can use the hack.
If you disable the keyboard with the "\Z" key, you should have \Z assigned to a big stroke so that you can re-enable the keyboard. If you disable the keyboard without a big stroke to re-enable it, you can still get it back by switching applications: the hack responds to appStopEvent by re-enabling the keyboard and clearing all shift states.
- Problem with lists on Pre-OS 3.5 machines: My code seems
unable to set the usable state of lists and gadgets
programmatically; the usable bit in the resource file applies for
the duration of the program. The only reason I can show/hide
popup lists is because I'm using LstPopupList which does its own
thing... However, the keyboard gadget does not display at the
wrong time because I put in some special code prohibiting the
displaying of the gadget except on page [4].
- Hack and database are not beamed with the config app. As a
workaround for the hack, at least for X-Master users, you can
beam it using X-Master's beam function (other hack managers
probably have a beam function too).
This is the initial public release. Here's the description I gave with my SourceForge application:
This project will implement a virtual keyboard on the silkscreen area of a PalmOS device. This requires that the program be a 'Hack', in order to intercept system calls, but as I'm having difficulty figuring out how to make it a hack, at the moment it is merely a standalone application, pre-alpha stage.
Anyway, its basic function works. You can input a layout in the Edit screen, then render it and use it on the Test screen. You can have multiple layouts; layouts can be duplicated, erased, and switched between. It has a "macro" feature; each macro can either input a series of keys or run a program, although the latter is not yet implemented.
A layout consists of up to five rows of keys; each row can have a different setting for height, key width, and alignment (width of the leftmost key).
Mind you, there's already a little program for getting keys on your silkscreen area, and it's called DotHack. [it's based on a previous GPL program, but for some reason source is not available...oh well] So why make another program? As well as being able to use the entire silkscreen area, not just the graffiti area--thus allowing an entire Qwerty keyboard to fit--MilliKeys supports "short strokes". A short stroke (as opposed to "big strokes", which I'll get to later) is a stroke where you press the pen down on a key, then move it in one of eight directions (up, right, up-right, etc.) and let go. This feature alone allows up to nine characters or actions to be represented by a single key. Additionally, when the program is finished it will support a shift and a caps lock, providing access to a predefined set of capital letter mappings, and a user-defined "extra" layout, which is kind of a user-defined shift/caps lock.
In the built-in layout the user can tap for lowercase keys; stroke up for uppercase; stroke down on the top row for numbers; stroke horizontally on the top row for punctuation (!@#$ instead of 1234); stroke down, left, or right on the second row for much more punctuation including extended characters; and stroke left anywhere on the bottom two rows for backspace. Finally, the "extra" layout contains accented characters. I have created a bitmap depicting this layout, which users can print out and tape on their PalmPilots.
It supports "big strokes"--strokes from the lower left or lower right to some other corner of the screen. The capability of a big stroke is the same as a macro.
Eventually I plan to implement a smart Graffiti passthrough feature where the program will detect irregular strokes and let Graffiti handle it.
[ Home Page @ SourceForge / Geocities | SourceForge Summary | Qwertie's Page | Code Notes | Manual ]