Poppler-Symbian pdf viewer

So yesterday, i grabbed poppler, freetype and Qt sources and in 45 minutes hacked together a proof of concept PDF viewer for symbian. Pretty cool if you ask me, the ugly side is that if i ever get some more work on it and want to get it into OVI store I need to pay 50€ to register into it and around 200€ more to get the app to go through Symbian signed, of course what i'm not going to do is spend 250€ to get a free app into OVI store, on the other hand i could of ask for some € for the application (3€?), but i'm not sure it's a good idea either.

Another free software kernel

Symbian just made their kernel Free Software so if anyone is interested in real time, multitasking, SMP-ready kernel that is in use in lots of phones, you have something to hack on now :-)

Qt for S60 not as cool as real Qt

Ok, Qt for S60 *is* real Qt since it was merged in mainline Qt not too much ago, but it still has lots of things that make it not the very good toolkit we are used too. For example Qt 4.6 in S60 will have a QFile that won't support unicode names in files. :-(

Even more symbian woes

Symbian has pthreads support, but it sucks, yesterday i discovered it has a maximum number of threads you can create, that is

void *dumb_thread(void *)
{
pthread_exit(NULL)
}

function_somewhere_in_my_code()
{
pthread_t t;
int error = pthread_create(&t, NULL, dumb_thread, NULL);
check_error();
pthread_join(t, NULL);
call_function_somewhere_in_my_code_though_a_timer();
}

will end up returning error 35 (EAGAIN) in pthread_create after some calls, depending on the phone it can be 20000 or 60000, and yes, that's a lot of threads, but if you are using threads for fire and forget jobs it's relatively easy to hit that number, so i've been forced to implement a thread pool just to workaround yetAnotherSymbianBug.

And yes, this has nothing to do with KDE, except that the more i code in Symbian the more i appreciate the rock solid API provided by KDE and Qt

Symbian stringstream woes

Here i am, wondering why the hell Symbian code is so bad after all the years that have passed since it was created. I was bitten by the "select() memory leak" bug some months ago and now i've been bitten by the "stringstream is not thread-safe" bug. One wonders if such simple things fail[1] what more can be hidden in the deeps of the Symbian code, i think it's time for the Symbian Foundation to open up the code already.

[1] Ok, actually the "select() memory leak" got fixed (or so i was told) after i reported the bug in the Symbian Foundation bugzilla and the "stringstream is not thread-safe" seems to be fixed either in the OpenC/C++ 1.5.5 beta that can be dowloaded from the trolls site or in the new firmware for the N78 (can't tell which one fixes things as i updated both)

Symbian C++ sucks

Let's say you are developing on a Symbian phone. You are creating something more complex than a "Hello World" app so you need threads.

You create a RThread, and inside that thread you append things to a RArray (dynamic array) and then from the main thread you want to retrieve them.

NO! You can't! Accessing elements of a RArray from two different RThreads is not allow and it'll crash on you.

Ok you think, they just ported STL to Symbian, let's use a std::list, and NO! It'll crash even earlier.

So you are about to throw the phone across the window, but then you think, wait the also ported some POSIX things to Symbian, and try pthread and it suddenly works and you realize how simple things can be a nightmare when using weird tools/SDK, that's why Qt rocks it gives you almost all you want in a practical API, and when something is missing KDE adds the missing bit.