Notices

One of the neat features in hildon-desktop is that it can use PVR screenshots that can be loaded before an app starts, just to make it look like it started faster, unfortunately, most apps on Maemo 5 don't support this, a few stock ones (Clock/Settings/Modest), and very few community ones (fMMS, DrNokSNES, PSFreedom etc...) do.

This is a quick app that allows you to create PVR images, they will be saved in /home/user/.cache/launch/org.maemo.pvrcreator.pvr.
After an image is created, rename it to match the service name of the application you want to use it for from /usr/share/dbus-1/services/
Use this command:
to get a list of service names, rename the pvr file to the name you got from the command above, adding .pvr at the end.
Example:
Take a screenshot of the media player.
Trim the top title bar (including status menu etc...).
Place the edited screenshot somewhere on the device.
Use the application to create a pvr file.
Rename the file to com.nokia.mediaplayer.pvr



Thanks to thp, Jaffa, and frals, their source codes really helped in this app

Package name is pvrcreator, should be in devel in less than half an hour.

Some notes, I case others also stumble like me:
It only works, when you start pvrcreator via the menu.
If you start it in the terminal, it will not work!

Also you will have to create/modify 2 files. Have a look on those 2 files:
/usr/share/applications/hildon/YOURAPP.desktop:
/usr/share/dbus-1/services/YOURAPP.service:
The pvr file has to be in the folder /home/user/.cache/launch and has to have the name org.maemo.YOURAPP.prv

Thanks MohammadAG for this trick to get a false instant startup feel. I used this trick on my PyQt4 application but dbus service terminate my app after a couple mins running, unless I either have to use run-standalone.sh to start up my app or include import osso and self.osso_c = osso.Context("com.myapp.app", "0.0.1", False). Any reason why? or other any other right way to do it?

I just noticed that the same thing happened to your apps as well.

Glorious.

I pray that all maintained packagers start using this and we can start backporting it to "important" applications.

Which apps? I'm pretty sure DBus launching works fine.

Also, here's a method to do it in C++/Qt:
https://gitorious.org/qt-mediaplayer...ow.cpp#line539

Your pvrcreator app, I was talking about, which closed itself after a couple mins. or so.

Am I the only one who doesn't like this "false fast start-up"? When I see a program appear, I want to be able to start using it - right now programs that do use this false impression of quick launching just trick me into poking the screen before the damn thing actually loads. And then I have to wait the same amount of time before using the program anyway. And I know I'm not so awesome that my brain/reaction speed would be any faster than that of m ost people, so it surprises me that this doesn't bother other people as much.

For example, with the Settings menu program - I just remove it's respective .pvr file and touch the same name as root, so it can't override it. This way I get a nice black screen until the thing _actually_ loads, none of this program lying to me thing.

And at least for my mind it also feels faster, because then I don't have this impression of ...waiting... while the app actually loads. I know the screen is black so I know the moment it gets colorful I will have my program loaded, where as with pvr image I have to wait for the tiny visual cues that show the program actually loaded.

A visual indication of loading over the entire drawn window would be better - similar to how webOS does the "glowing" application logo.

The problem is that we're running all this interpreted code that requires runtime engines and on-the-fly coversion, which, IMHO, has no place being called "apps", especially on a device that was not built with the framework in mind. webOS was built with it baked in and it works spectacularly well for that.

I for one, will take native code and straight binaries over QML, Python and whatever else, any day of the week on the N900.

Having said that, I still think this is a good idea. Snapshot before window destruction and paint that snapshot while the application is briefly loading - yet still displaying the title bar "spinner" to indicate this.

it seems to me that specifying "X-Osso-Service=org.maemo.YOURAPP" in your app.desktop file without initializing the osso in your app code will cause your app to be terminated by the dbus service shortly after the app started up, except the app was launched through run-standalone.sh medthod.

Funny, the moment you mention this is when I started getting it with Sociality.
I'm a bit stumped here, my old Qt apps were launched in the same way and used more memory, and weren't killed (SIGKILL after 120s)

Edit: you're right, I was looking at PSFreedom and apparently I used to use run-standalone.sh for that, but the mediaplayer wasn't DBus aware and doesn't crash in 2s...