I was looking at two different possible paths for the next step in the process of porting BBSSH to the PlayBook.
A common problem to be addressed with both is packaging the app in such a way that it will launch properly with a UI – but I’ve not yet gotten that far.
Option 1 - a hybrid interface, using AIR to provide the UI and rendering only, and a custom C library to manage terminal(s) states, handle connections, etc. This was the most appealing, because it’s relatively simple to make UIs in AIR; and the actual painting logic for a terminal is pretty straightforward. State management (eg terminal emulation) is a lot more complex, and not something I really wanted to write in ActionScript.
Option 2- a “pure native” interface. Since RIM has announced that there is no UI capability in the native toolkit, this means I’d need to use OpenGL to handle UI and rendering.
Both of these would be backed by a custom library to handle terminal state, telnet connectivity, libssh, etc. This architecture will also make it trivial to provide additional services – such as running a local shell on the PB through the app, or using BBSSH bridged via bluetooth; similar in principle to the bridged BB apps we already have, this would let your connections, keys, etc remain on the BB while the PB app just does the rendering.
Unfortunately, I’ve run into a dead-end for Option 1. I was looking at AIR native extensions as the best means of integrating native code and AIR UI. Initially, it was promising – the AIR native extension capability is exactly what I need to do what I plan for BBSSH. I ran into two problems according to the documentation: in order to build, I would need a prewritten C++ source file that is included with AIR’s proprietary EDK. I have not been able to get this from any source.
Perhaps as importantly, the documentation states that the AIR for TV profile (that’s what is apparently on the BB) does not allow for native extensions to be deployed with AIR components. According to those docs, I would need to have my extension pre-installed on the device by the manufacturer.
While this likely isn’t entirely true (RIM has said in a recent BerryReview interview that native integration is possible though unsupported; and I came across a blog post from Adobe that also said it would be available) … and I”d be tempted to push ahead anyway… the lack of the CPP file means that I can’t actually author an extension to test the theory.
This leads me to the pure OpenGL front-end, which is carrying its own set of headaches:
- there is no UI library that exists for OpenGL which runs on QNX. This means creating things like list controls (for connection, private key, macro management, shortcuts, etc), pop-up windows, entry fields, checkboxes etc from scratch or porting an OpenGL UI library to work with QNX.
- OpenGL itself does not handle window management; and as far as I can tell (I’m still learning OpenGL) it can’t run independently of an OS-specific window management integration layer. The standard libraries like GLUT have not been ported to work with QNX as far as I can find.
Which means in order to get where I need to go, I need to look into the native windowing functionality of QNX and the QNX OpenGL integration functions. (Windowing and integration in this way may not be supported on the PB itself, which is a separate concern)
All in all, this part of the process is turning out to be just as much a headache as I expected it would be 
I’ve not given up yet, but the going is slow. I’ll post news when I have it.
