About the pmenu thing: I've already told him, but the thing is that it's already struggling with rendering a constant 30 FPS (albeit with GL ES emulation, but my GPU is pretty darn fast so that shouldn't be the issue) so there's a bottleneck somewhere in the app that a thread yield/sleep cannot eliminate... I should run valgrind on it some day...
skeezix said:
Perhaps I posted /mnt/sd[12] in a wiki somewhere? Let me know, maybe I shoudl correct it
No, no, I actually tested pandora-libraries with those paths and just started using them in Panorama too. I'll create a patch for Panorama immediately that uses the correct mount points, np (I'm already opening /proc/mounts anyways as you can see).
The clock: I just use Qt for that, and it does its magic to generate an accurate clock source for me. Setting the clock... well, that may be useful too, we'll see.
Scripts: Actual method calls or even opening files are faster than any script invocation, so I'll stick with those, but maybe I will copy some of the code from the scripts to see how some of the more obscure information is being extracted
But I know the pandora-libraries repository's contents by heart by now from all the hacking, so I'll find them on my own, you don't have to bother.
And yes, I'm also aware of pnd_device.c, so I know what's there, don't worry!
Btw, I'll probably be forking pandora-libraries in the future, not to add custom crazy features, but to do some maintenance work, fix the Makefile (so that it generates the correct symlinks for libpnd.so.1 - because LD can't find it in its current form! - and also so that it respects the CC and CXX env variables, things like that), and I will also do some code clean-up because gcc 4.4.2 spits out warnings at me every time I compile pandora-libraries. I might also reorganize the dir layout a little bit so that I can compile it using qmake which is useful for cross-compiling Panorama - I currently have to change the Makefile manually to include "-m32 -march=..." flags when compiling for i686 which is cumbersome.
All in all: I'll make changes to the repo that fix some basic stuff, but I don't know if the changes will be worth pulling into the main repo, because you might have some secret purpose behind putting source files in a folder called "lib" etc (maybe for bitbaking scripts, I don't know), so it might be best if I maintain an external fork that I pull changes into from time to time from the main repo.