Skip to content

Patched openFrameworks 0071 for the QNX platform (BlackBerry PlayBook & BB10) #1587

wants to merge 3 commits into from

5 participants


This patch adds support for the QNX platforms (BlackBerry PlayBook & BB10) to openFrameworks.

The code is based of the developPlayBook branch ( that has been used for the NodeBeat project ( However, I have updated the code for compatibility with openFrameworks 0071 (develop branch)

The current code has been tested using the following SDKs

  • BlackBerry PlayBook Native SDK 2.1.0 beta 1
  • BlackBerry 10 Native SDK 10.0.06 beta 2

To develop for QNX or run the examples, you will need to download the ofxQNX add-on and place it in the addon folder of openFrameworks.

For now, ofxQNX resides in a different repository for the following reasons:

  • Because I include pre-compiled libraries, the current size of the repository is about 100 MB.
  • Pre-compiled libraries are used because of the complexity involved with building them from scratch. Most of them need to be patched for the QNX compiler and Poco for QNX can't be build on Windows platforms.
  • Another reason for the size (mostly due Poco) is because it supports multiple QNX architectures and build modes. The devices all use an ARMv7 cpu, the simulator uses x86.
  • > PlayBook device (ARMv7) - Release
  • > PlayBook device (ARMv7) - Debug
  • > PlayBook simulator (X86) - Debug
  • > BB10 device (ARMv7) - Release
  • > BB10 device (ARMv7) - Debug
  • > BB10 simulator (X86) - Debug

Additional info on ofxQNX:

falcon4ever added some commits Sep 11, 2012
@falcon4ever falcon4ever Patched openFrameworks 0071 for the QNX platform (BlackBerry PlayBook…
… and BlackBerry 10)

To develop for the BlackBerry PlayBook and BlackBerry 10 platform:
- Download ofxQNX ( and install it into the addon folder.
@falcon4ever falcon4ever Enabled QNX output log cec0279
@falcon4ever falcon4ever use absolute path on QNX platform 3d75860

i'd like to ask the core how they feel about this -- it's been sitting here for a bit. @ofZach @ofTheo @arturoc

it's awesome to see people contributing to OF in a way that opens it up to more platforms, but my feeling is that QNX is not popular enough to warrant merging into the OF core. if there is a way to make this work without requiring QNX-specific changes to the core, that would be really cool.

for now i'm going to close this PR unless zach/theo/arturo have a plan for incorporating this kind of work.


@kylemcdonald: Just a small update on this PR, this one was done quite a while ago with an older version (0071). The patches for 0.7.4 are now in


cool -- good to know it's still possible to get OF working on QNX :) i hope there's something we can incorporate from all this work!

openFrameworks member

@kylemcdonald judging from this PR, it seems the necessary changes are primarily a bunch of finer-grained ifdefs, so not too invasive I think. Maybe we can do some kind of "unofficial" support, i.e. just have the ifdefs in Core, everything else is in the addon anyway? I guess it depends how committed @falcon4ever is to maintaining QNX support? Alternatively, @falcon4ever could just keep maintaining a patched OF branch in his repo like currently.

ofTheo commented Jun 15, 2013

it doesn't seem too invasive: falcon4ever@93598c7

@falcon4ever - what could we do on our end to make it easier to keep it working for QNX?
Is it similar to iOS where there are some #ifdefs in the core and then the rest in an addon?


@ofTheo Yep, pretty much like iOS or Android. I have only patched a handful of files in openFrameworks to add QNX support. Since the BB Native SDK doesn't have the tr1 memory/shared_ptr implementations, I borrowed them from boost. For poco I'm using the same version (1.4.3) as in the repo. It works fine with the poco you guys patched ( 8a59e32 )

The rest is all handled in the addon ofxQNX ( The readme contains the changelog and details about the libraries that I include.

Since this pull request is 9 months old and was made for 0071, I think it would be easier to just create a new pull request based on the latest dev branch / v0.8.0. The rest of the add-on can stay in which I will maintain.

openFrameworks member
arturoc commented Jun 17, 2013

sounds good to me too, everything opengles related is now properly ifdef'd for opengles instead of iOS and i guess there's little more that need ifdefs since i think this should be pretty similar to android or arm linux.

also we can avoid using boost by typedefing ofPtr to poco SharedPtr instead.

i would add the libraries in the official OF repo so it's easier to generate official packages?

openFrameworks member
arturoc commented Jun 17, 2013

also, i've heard that there's a tool from RIM to convert android apps to their new OS. have you tried that? it could be an option too but not sure how well it works

openFrameworks member

i would add the libraries in the official OF repo so it's easier to generate official packages?

the thing is, when we do that, we'd have to maintain it in the future, too. do we even have devs who use BB devices (except @falcon4ever)?


I personally would prefer to keep the libs in the ofxQNX repo as they are updated quite frequently. Blackberry is working quite hard to update its platform so in the couple of months they did a few major upgrades (10.0.09, 10.0.10 and now 10.1.x). ( )
Besides that, the libs folder is quite big (70+ MB) so that might pollute the openFrameworks repo quite a bit (perhaps make it an optional submodule in the addons folder?).

@arturoc The tool from RIM only allows you to convert Android apps that are implemented in Java only. It checks all the API calls that the app will make and gives you a report. Native libs are not supported (well officially that is, its disabled on purpose) so you can't just create an *.apk and then convert it to a *.bar and expect it to run.

About boost, yea if that is a possibility I could probably drop the boost dependency in ofxQNX.

@bilderbuchi I dont know how many people are using it, probably a handful of indie devs. I've used it for Nodebeat and Super Hexagon but I believe Breakeroids from Simon is using it as well.

openFrameworks member
arturoc commented Jun 17, 2013

I personally would prefer to keep the libs in the ofxQNX repo as ...

sounds good, i would try to look into using SharedPtr for ofPtr to avoid having boost, let me know if you need help

@falcon4ever falcon4ever deleted the falcon4ever:develop-0071-qnx branch Dec 22, 2013
@falcon4ever falcon4ever restored the falcon4ever:develop-0071-qnx branch Dec 22, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.