While I wasn’t able to get the posts transferred over, bbssh.org has been updated to start using the tried and true WordPress blog.

You can find it here – look for some exciting (to me) new updates about BBSSH this weekend:

http://bbssh.org/blog/

And of course if you’re a twitter fan, new blog posts and other info are posted to the project’s twitter feed:
http://twitter.com/bbssh

• Google talk/live chat/et al — IM+ and one or two others.
• Twitter -> UberTwitter and others.
• Podcast app -> Podcatcher

This is a worrisome trend as individuals and companies have devoted considerable time and resources to creating apps for sale in the RIM app store — only to be undercut with free apps released by RIM itself.  What’s to say that tomorrow, they’re not going to release an SSH client?  Or any of the other apps that make this platform great?

Competition is a good thing (frankly – the commercial offerings in all cases are better than what RIM has developed) but this is kind of like they’re saying, “Hey, thanks for contributing to our available Blackberry apps and helping to build a customer base.  We also really appreciate the great app ideas. Now f!@# you.”

It really has to give any new (or existing) BB app developer pause when considering whether this is a platform worth building on.

The only problem is that they both get it backwards.  As you use something more often, it migrates higher up the list — that is, further away from where your mouse starts out.  The newest items (least frequently used) on the list are the ones that are closest to your mouse from the start.

Wouldn’t it make sense to move the items you’re more likely to want to use closer to your mouse instead of further away?

Just a thought…

http://bbssh.org/roller/bbssh/entry/information_gathering

Here’s the other, a preview of upcoming features in 1.1.9:

http://bbssh.org/roller/bbssh/entry/big_changes_in_next_release

Just a reminder to update your bookmarks to point to the new blog at http://bbssh.org/roller/bbssh; and to grab the new feed from the same place if you’re interested.

Of course you’re welcome to continue to monitor this site too – I expect to start discussing more general development topics that may not directly relate to BBSSH.

http://bbssh.org/roller/bbssh/entry/bbssh_1_1_8_alpha

For those who just want to get to the good stuff, you can snag the OTA download here:

http://bbssh.org/ota/

The bad news is twofold. First, JIRA is a great tool but is also very heavyweight. I’m concerned – especially in light of BBSSH’s growing userbase – that the VPS host for bbssh (which will also hold a couple of other sites of mine) might get overwhelmed. In that case we might have to fall back to something like JTrac, which is much lighter weight (though also not as feature rich).

The second is that the conversion took much longer than it should have, which means the help docs didn’t get online as planned this weekend. Look for this to start appearing over the course of this week.

http://bbssh.org/ota/

As I mentioned earlier, this release contains many minor (and a couple of major) bug fixes. Originally I wanted to wait until after the key-binding customization as complete, but I didn’t want to delay the release any longer while I continued to fight that.

Unfortunately, this release will wipe your saved sessions and keys.  I am working on a fix for that for next release.

Content in this release:

• Corrected issue where if a server supports both SSH1 and SSH2, BBSSH mis-interprets as SSHv1 only and refuses to connect.
• Added new menu item to terminal emulator: Show Symbols
  • This shows the standard symbol menu, and is also bound to key Right-Shift+SYM on non-touchscreen BB.
• Added new menu item to terminal emulator: Show Special Keys
  • This shows the “special keys” menu, including F1-F12 and others. This is also bound to ALT+VolUp
• Added new menu item “Send Feedback.  Use this to send feedback email about BBSSH.  This is available from the main screen and the terminal; on the terminal it will also prompt you to include a screenshot, if you should want to.  This is included for bug-reporting purposes.  Your BES policy may prohibit attachments, in which case you won’t be able to send the email with a screenshot attachment.
• Added new default key-binding: Shift+VolDn .  This displays a list of all commands and their keybindings.  Currently has a bug which prevents you from scrolling the list.
• Added online help framework: you’ll notice several screens now have a Help menu.  Clicking this will take you context-sensitive help online. Currently the web service is in place, but help content is missing. This content will get added gradually over time.   Screen- and field-level help will be supported.
• On Session Properties screen: added “Save and Close” menu option to make it a bit more clear; and also the confusing message that displayed when you did not included a hostname.
• Added graceful error handling for failed update check on the Settings screen.
• Fixed the input overlay in several ways (remember, input overlay is bound to VolUp by default):
  • Correctly positioned at the bottom of the screen. Increased font for readability.
  • Proper Enter key handling has been added:
    • Enter – close the input window, send the text, and send the Enter key
    • Shift+Enter -> close the input window, send the text, and do NOT send the Enter key
    • Alt+Enter -> insert a newline into the input window, do NOT close the input window or send the text.
    • ESC now closes the input window, clears the text, and does NOT send the text

Some internal changes too:

• Subversion repository now moved to svn.bbssh.org
• Converted to Eclipse IDE instead of netbeans.  While I much prefer netbeans, the RIM development support simply isn’t there for any IDE except Eclipse.
• Created ant-based build scripts for standalone deployment
• Changed base package names to bbssh.org.
• Split into separate projects for easier resource management and testing
• Added new “SessionManager” and “ScreenManager” to offer more flexible options  in terms of session connections and bindable commands.
• Did some performance profiling and found that the custom crypto is hands-down taking the most CPU resources during a normal session.  This means that switching over to BB crypto is highest priority (alongside some low-hanging bug fixes

Please continue to use the sourceforge.net tracker/bug reporter for issues and requests until the move to bbssh.org is completed this weekend.

As mentioned in the 4/22 update, a FAQ will be online soon — once the new site comes fully online this weekend. There are several questions posted over the last few  weeks that will be addressed there.

Comments and feedback are appreciated as always.

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)…

I’m compiling that info and a bunch more into a FAQ and an actual project web site — something more than a blog . I’m also moving away from sourceforge due to various issues. I expect most of this to be online for the weekend — I’ll announce the new site at that time.

1.1.7 is also fairly close to ready as well — it’s got several key bug fixes, but I’m also pushing to get key binding customizations included (that’s the delay – designing a user-friendly mobile UI for that is proving more complex than I expected ). I may release with an interim version first, just to get it in your hands for early feedback.