Note: this FAQ is about the first release of the PDK. This is not the final version of things that will ship on device.
(Update 1: clarified camera and microphone access to indicate that you can mix Mojo and PDK to get access to images)
(Update 2: this FAQ is now an official Technical FAQ and hosted at developer.palm.com. Go there for the up-to-date version.)
Why does nothing happen when I try to launch this PDK application on my device?
Did you run the pdk-device-install script to put the PDK libraries and system support code on your device? If you didn't, most PDK apps will install but won't startup.
Can I develop using the Palm webOS Emulator?
Not at this time. PDK applications are compiled to ARM code, while the emulator uses x86 code like your desktop machine. We provide host libraries for Mac OS X and Windows to test most of your PDK application on the desktop, but this doesn't include support for integrating a PDK component with a Mojo application or calling any system services.
Can I access the microphone using the PDK?
Not at this time.
Can I access the camera using the PDK?
Not directly. You can create a hybrid application using both the Mojo SDK and PDK where the Mojo part captures an image to the device storage, then it calls into the PDK component to do further image processing. However, you can't directly access the data from the camera without going through the Camera app.
Why can't I use the SDL_Image support for loading PNG or JPEG files?
This is a bug in the Mac version of the SDL host libraries. Loading of those images works on the device and in the Windows host. This was a build error with the Mac host code and will be fixed in the next PDK beta release.
Why do I get a linker error about "unresolved external symbol _WSACleanup@0" when I build for Windows?
The sample project doesn't link with the Windows Sockets code from the Windows SDK. Add WS2_32.Lib to your additional dependencies list.
I get a bunch of errors about missing libraries when I build the native version. Is this OK?
Those are warnings about the linker being unable to resolve all of the shared libraries needed for the device build. This is OK; we don't include all of the shared libraries so we can avoid unneeded dependencies on the version of webOS that's on the device. There's no way to silence this warning with the version of GCC that we use, although we're looking at modifying the local .so files shipped in the PDK in future releases to remove those dependencies.
Will installing OpenSSH on my device through palm-device-installer leave open a security hole?
While OpenSSH listens to port 22 and the "root" account has no password, your device is safe because the firewalls running on the device only allow connection to port 22 through the USB connection, not through WiFi or the carrier networks.
How do I handle the back gesture?
Look at PDL_types.h; you'll see that the back gesture sends key 27 (the Escape key), while the forward gesture sends key 229. Use PDLK_GESTURE_BACK and PDLK_GESTURE_FORWARD in your code for clarity. You'll get these in your application as SDL key events.
Why doesn't my application run on the Palm Pixi device?
Our Pixi support is very early in this revision of the PDK, but you should be able to run pdk-device-installer on a Pixi device and do some early testing. Make sure your buildit script is using the settings for the Pixi, the default settings are for the Pre and use ARM instructions that aren't available on that device.
Can I use the standard C and C++ libraries?
Yes, they aren't listed explcitly in the documentation, but you can rely on the standard C library being available. We ship GLibC 2.5 on the current release of webOS. For C++, there may be an incompatibility issue between the CodeSourcery tools on Windows and the device libraries with this first release which can affect some C++ applications, and we're working on resolving this for a future PDK release. If you do use C++, make sure you use the arm-linux-gnueabi-g++ tool to link your application to ensure that the correct support libraries are included in the output binary.
How do I use Unicode strings in my PDK app?
The C language has a easy notation for wide strings using a "L" prefix before the string to tell the compiler to use wide characters. However, there's a type clash between the standard widths for Linux and the GNU C library versus Windows and SDL. With GCC on Linux, if you use L"string" notation, you'll get 4-byte large characters since the default wchar_t size on Linux is 32-bits. If you need 16-bit wide characters so you can call the SDL Unicode calls, you'll either have to convert at runtime or use the -fshort-wchar option to the compiled. If you use the option, make sure you don't actually use any wchar_t types or calls, since the device's standard library remains set to 32-bit wchar_t. The L"string" notation with Visual C++ on Windows will always give you 16-bit characters.
If I register a method using PDL_RegisterMojoHandler, when will it get run?
Method handlers are called in a separate thread from the rest of your PDK application. That thread is started when you call PDL_MojoRegistrationComplete and it gets removed during the call to PDL_Quit when your application ends. You need to use thread-safe variable access when sharing data with the main PDK thread that's used to draw to the screen and handle SDL events.
How do I know when to quit?
Your application will receive a SDL_QUIT event when the user has dismissed its card. You shouldn't exit until you get this event.
How do I know when my application isn't in the foreground?
When your application is no longer the foreground card, you'll get a SDL_ACTIVEEVENT event with the active.gain value set to 0. When you're brought back to the front, you'll get the same event, but active.gain will be 1.
In what order do I call PDL_Quit and SDL_Quit when my application exits?
First call PDL_Quit, then call SDL_Quit. PDL_Quit may use SDL code, so it needs to be shutdown before you shutdown the SDL system.
How should I allocate my display window when using SDL?
screen = SDL_SetVideoMode(0, 0, 0, 0);
When you give it a value of 0; SDL assumes the most optimal size and pixel depth for your purpose. This will work on Pixi and the Pre. On the desktop however; you will see your app go full-screen which is a little annoying, so you may want to #ifdef this call to explicitly request a 480x320 or 400x320 window for host code. You can retrieve the width/height from the SDL surface that is created to modify your applications behavior for the different sizes. (Thanks to ChrisT from Palm for this explanation!)