marc paradise

I am struggling with a good way to present a UI for an inherently complex operation in a simple/usable way: customizable key bindings.

There are several moving parts involved in this. On the “input” side – you have the keystrokes. This means what the user presses, specifically the hard keys that I can intercept: send/end/cancel/menu, volume up/down, left/right convenience key, mute button, symbol key (except Storm), trackball movement, finger swipes (storm).

This key can be modified by any one of: Alt, Left Shift, Right Shift.

This by itself is not too bad. Creating a field that can intercept these keystrokes and display what is sent was straightforward (the bbssh keybinding screen currently has this).

Displaying and configuring whatever is currently bound to a given key combination is where things get complex.

The complexity comes in the form of parameters: you can (for example) bind the command “Send Keys” many different times — each time using a different keystroke parameter.

Other commands — like “Show Symbol Menu” have no parameters. And certain commands “send movement key” or “run macro” accept only a limited range of specific parameters.

On top of this, there are two ways to present this info. One at a time (based on the keystroke that has been entered) or in a list of bound keys. The first is good for looking up key bindings, while the second seems more convenient for fast editing/changing of them.

Actually, writing this out has helped — I think I know now how to do this without it being too insane.

The main interface is a list, which you can filter by entering binding keystrokes – example: press lshift+end and it will reduce the list only to whatever is bound to that combination.

Or type in the first few letters of a command like “move” and it will show only bound commands that contain that text.

(Display of this list is also a bindable command, so you can view your key mappings at any time in-session)

For each command you can change the key that it’s bound to by clicking on a button inline; and change the command that is run (or its parameters) the same way. List row would look like this:
| Key Combination — Command: params |

Click on the button for Key Combination to change that, or the Command button to change those options…

You can also unbind any selected command through the context menu, or bind a new command through a menu option

If you do have any suggestions or examples of a similar interface in a mobile app, please do share them; or if the interface described above seems like a good (or bad idea)…

RIM provides us with a powerful API for developing Blackberry applications.  They’re making improvements in the ready availability of good documentation (slowly).  They really seem to be responding to both their community and the threat posed by iPhone and Android.  For all of that, though, their toolchain still sucks.

Presently, we have two supported options for developing Blackberry projects: use the RIM JDE (if you’ve tried to use it, you know that this isn’t an option at all); or use their Eclipse/JDE plugin.  Outside of that, you’re pretty much on your own.

I’m a long-time Netbeans fan — I’ve tried Eclipse multiple times, and I just don’t get along with it.  With a bit of headache and digging, I’ve been able to get most BB development tasks working in Netbeans.   Until this week…

In working on BBSSH, I realized that people may eventually want translations, so I set out to use the provided localization features of the Blackberry platform. (Also, all those raw GUI-related strings in my code were annoying me.) Unfortunately, because I don’t fall into the “JDE” or “Eclipse” categories mentioned above, I fell into the third: pretty much on my own.  In hopes of preventing the next person who attempts this from falling into the same category, I figured I would write up how I worked this.  Note that this isn’t necessarily the best or the only way – but it does work, and it does not add a lot of pain to the process.

This tutorial assumes you are familiar with Netbeans, and have some familiarity with the JDE. Read on for more. For the impatient, you can skip straight down to “3. The solution”.

(continue reading…)