Making a Keyboard

My ancient keyboard

Back to Woopsi coding. There’s not much left to do until it can go into feature-freeze and alpha status.

The easiest thing on the remaining list of things-to-do is the keyboard gadget. I actually started work on this a few months ago. It’s nothing more than a window with a few dozen buttons on it, each one representing a key on the keyboard.

I’d initially planned to follow the design of real PC keyboards, with the row offsetting that you can see in the picture above, but that doesn’t really work. The buttons need to be large so that typing text isn’t any more frustrating than it has to be. The layout needs to mimic the layout of real keyboards for the same reason, so the “[” and “]” keys need to be on the same row as the QWERTYUIOP keys. They can’t wrap around onto the next row down. This leaves me with a boring but usable grid layout (WIP grab):

Woopsi Keyboard WIP

I created this layout whilst using a PC, so it looks very odd when compared with the Mac keyboard I’m using now. Just need to add space, return and modifier keys and the layout is sorted. When it’s done, the keyboard will fire EVENT_ACTION events each time a button (ie. key) is released. The class will have a “lastKeyPressed()” function (or similar) that identifies which key caused the event.

Behind the scenes, this is called the “WoopsiKeyboard” class. For some reason the code wouldn’t compile when I called the class “Keyboard”; I imagine something in libnds has the same name.

I’ve also fixed a bug in the “packedfontbase.cpp” file. It was including “PackedFontBase.h” instead of “packedfontbase.h” (case mismatch) preventing the code from compiling in Linux. Thanks to Gattman for that one (via SourceForge).

Better get back to it, then. Not the most exciting blog post, but I’m trying to ease back into Woopsi work slowly.


Jeff on 2008-10-02 at 03:58 said:

Personally, I’d spend a little more time making it bitmap based (or something) rather than having a bazillion little buttons. The buttons make implementation easy, but waste screen space (for the shadows and gaps between keys.

Are you planning on doing keyboard repeat somehow?

Oh, and one thing that annoyed me about the iPod Touch MobileTerminal keyboard is that it doesn’t expose control-keys, which makes entering ^C or ^D impossible. Woopsi could be a good framework for a cheap telnet client…

ant on 2008-10-02 at 06:17 said:

I considered making the keyboard look better by using bitmaps, but it comes down to RAM size - is a pretty keyboard worth 96K of the 4MB that’s available? Perhaps I could include a second, bitmap-based keyboard in the bonus folder.

I like the gaps - they make the keyboard easier to use, especially with my DS. The touchscreen is getting less and less accurate as it gets older.

Control keys are a good idea, I hadn’t considered the terminal requirements.

Keyboard repeat is easy - just do it the same way as the slider buttons repeat (stick the keyboard into the VBL list and keep firing events whilst the keys are held down).

Jeff on 2008-10-03 at 23:52 said:

The keyboard doesn’t have to be a fixed bitmap that fills the screen. With the HP, I pre-rendered each segment of the LED’s and then construct them at draw time and it works plenty fast enough.

You could pre-render one button up and down, and just re-draw it over and over according to a pre-computed set of coordinates, then draw the text over the top.

Perhaps my real concern is having an additional 40+ objects loaded into memory - if nothing else, its going to churn your heap, making it more likely that later “big” allocations fail.

ant on 2008-10-04 at 07:30 said:

Yeah, good points. It would mean making a gadget that used collision detection with the stylus and a set of rectangles instead of the built-in button functionality, though. Think I’ll stick with the button-based keyboard as the “official” one, since it follows the existing standards of code design and appearance, but have a secondary keyboard in the bonus folder.

Jeff on 2008-10-05 at 22:19 said:

The nice thing about doing the bitmap+rectangle keyboard would be that it would push you towards doing grafPort::drawSubBitmap() to make the keyup/down code easier. In the HP, I copped out and drew a fuzzy rectangle around the depressed button…


ant on 2008-10-06 at 05:42 said:

Do you mean blitting a sub region of a bitmap to the screen? Shouldn’t be difficult to add. In fact, I’m sure I’ve written it somewhere; for the SuperBitmap, perhaps. I just need to move it across.

Jeff on 2008-10-07 at 08:18 said:

No, I think it was blitting a bitmap to a sub-region of a bitmap.

ie, I have a bitmap of a depressed key, and I want to blit it into the space occupied by that key within a bitmap of the entire keyboard.

ant.simianzombie.com » Blog Archive » Cursors and Bitmaps on 2008-10-31 at 20:55 said:

[…] bitmaps entirely in memory without an associated gadget. This should, I think, answer one of Jeff’s early queries. I’ll get around to stripping the code from the SuperBitmap and replacing it with the Bitmap […]

ant.simianzombie.com » Cursors and Bitmaps on 2009-10-07 at 12:07 said:

[...] bitmaps entirely in memory without an associated gadget. This should, I think, answer one of Jeff’s earlier queries. I’ll get around to stripping the code from the SuperBitmap and replacing it with the Bitmap [...]