08-22-11 12:57 PM
37 12
tools
  1. xsacha's Avatar
    If you use Photon, it won't play nice with the UI but it will work. What I've been working with is libscreen (what all the apps use), screen_create_context, screen_create_window.

    Yes, there's no /dev/photon, the apps all use /dev/screen actually.

    You can make a graphical app -- the problem is that devuser can't run them. You need to run them from the Playbook itself via a package.

    So I still can't get past the problem that none of my apps will even load (tried a simple mkdir console app) when packaged in to a .bar.
    Last edited by xsacha; 08-21-11 at 02:25 AM.
    08-21-11 02:23 AM
  2. FourOhFour's Avatar
    You can make a graphical app -- the problem is that devuser can't run them. You need to run them from the Playbook itself via a package.
    non-root user probably requires permission from authman to run screen code.
    08-21-11 03:15 AM
  3. dkonigs's Avatar
    So why won't you post code already? I don't care if its Photon-based or a few reverse-engineered libscreen calls. I just want to see something that I can build and try to run. Seriously, stop dodging the request at every turn.

    Its getting very annoying to see two people claiming they've had luck doing something no one else has, then not sharing how (in any reproducible way). I'd like to start attempting with packaging issue myself, and have had limited success in the past. When my attempts failed, I did still find log files indicating why, and the reason had more to do with bad API use than signing.
    08-21-11 08:22 AM
  4. HaTaX's Avatar
    I'll load up another VM with Momentics on it, I had tinkered with this a few months ago when I read the story on native apps. Since then the trial had expired and I just deleted the VM with it, didn't see a need to keep it as I thought the NDK was shortly around the corner. And truthfully we're now at the point where it is right around the corner, and it will save us the frustration and such of coming up with kludgy code ourselves. What's the purpose of smashing some code together and getting it to run if the officially sanction means is only a month or two away?

    As far as the Android player not loading with debug tokens after being modified, that has everything to do with the package name. Anything that starts with "sys." is considered a system level application and can only be loaded when signed by a specific key (RIM's). That's because these packages make modifications that require root level access to the system, not something they're going to allow just any developer to do. Android player creates new links off the root path "/" like /data and /sdcard, can't do that with the access that is given to a normal application.

    I'll build a new VM and get a new trial of Momentics installed in there, and I'll go dig for that perpetual license that I didn't know was out there till it was mentioned here. Once I get setup I'll recreate my app code that called the launcher. I used the scrapbook app as a basis with a little info from the NFS binary to get the needed system calls. Honestly I don't remember what all I needed to do to get it to work, it was one of those things I worked on in the middle of the night and was just more of an exercise than anything else.

    FWIW, I've had success in getting many different things "done" on the PB that I've not spoken about publicly and in detail. Releasing information might get you a few hours of fame, but it's not always the best course of action if the platform's best interests are important to you. Just my 2 cents...
    08-21-11 03:42 PM
  5. dkonigs's Avatar
    I believe this is the link for the non-commercial perpetual license:
    Non-commercial developers

    That being said, we all hope the NDK is right around the corner and this is all a moot point. The only plausible theory I've heard so far, as to why its not already out, is that RIM wants to keep some advantage for the "alliance partners" above what the rest of us have access to.

    (And that early versions of the NDK could theoretically have been little more than an extra BSP for QNX Momentics.)
    HaTaX likes this.
    08-21-11 03:50 PM
  6. FourOhFour's Avatar
    The only plausible theory I've heard so far, as to why its not already out, is that RIM wants to keep some advantage for the "alliance partners" above what the rest of us have access to.
    Reality is probably much more mundane than such a consipracy. It's more likely that APIs are still in flux and the documentation effort has to catch up. When the playbook launched, it was 18-hour days, 7 days a week up to launch date. I can guarantee you that a ton of that code was just done to "get it out the door", and has been under rewrite for the past months to prepare it for public consumption.
    While it's fun to hack things up, like HaTaX, I'd rather just wait the extra month or two and get the documented NDK
    08-21-11 07:06 PM
  7. biggulpseh's Avatar
    Sorry for a noob question, I know very little about coding etc. How hard would it be, once the Native SDK is released, to be able to port VLC player to the Playbook? I see that it's open source and written in C/C++... would it be a relatively easily thing to port or is it harder due to it using hardware acceleration with video etc?
    08-21-11 07:54 PM
  8. dkonigs's Avatar
    Sorry for a noob question, I know very little about coding etc. How hard would it be, once the Native SDK is released, to be able to port VLC player to the Playbook? I see that it's open source and written in C/C++... would it be a relatively easily thing to port or is it harder due to it using hardware acceleration with video etc?
    That depends on a lot of details of the platform that we don't know yet. VLC is also a large app, with hooks into a lot of things, so its even more a question of how easy it is to port VLC's dependencies than VLC itself. Of course the biggest of those dependencies, Qt and FFmpeg, will be high on everyone's priority list of things to port. (And those may already have QNX support at some level.)

    Of course porting the code itself is only half of the work. The other half is giving it a touch-screen-friendly UI. (Though its possible that someone has already done initial work in that direction, for other platforms.)
    08-21-11 08:09 PM
  9. xsacha's Avatar
    Anyone using "/pps/services/navigator/control?wait" for Playbook UI?
    Last edited by xsacha; 08-22-11 at 01:21 AM.
    08-21-11 11:18 PM
  10. dkonigs's Avatar
    xsacha, until you actually show us some code, I have a hard time believing you've accomplished anything beyond just running a command-line executable. Just because you can compile things that reference existing QNX GUI libraries, doesn't mean all that much.

    Why did you start a thread titled as a "Guide", then keep dodging any and every request to actually follow it up with a damn code sample?

    So I'll say it again...
    SHOW US THE CODE, OR IT DIDN'T HAPPEN

    All I've been able to deduce about libscreen, is that each of its methods takes a pointer to "something". (where I suspect that something is a struct defined in a header we don't have access yet)
    08-22-11 07:46 AM
  11. molson0's Avatar
    Sorry for a noob question, I know very little about coding etc. How hard would it be, once the Native SDK is released, to be able to port VLC player to the Playbook? I see that it's open source and written in C/C++... would it be a relatively easily thing to port or is it harder due to it using hardware acceleration with video etc?



    droid player
    08-22-11 09:07 AM
  12. FourOhFour's Avatar
    All I've been able to deduce about libscreen, is that each of its methods takes a pointer to "something". (where I suspect that something is a struct defined in a header we don't have access yet)
    those are mostly just opaque handle pointers.
    08-22-11 12:57 PM
37 12
LINK TO POST COPIED TO CLIPBOARD