Re: [Announce] [Beta] Applauncher port for Fremantle - launch apps faster and more economically
 

Great work marmistrz, looking forward to it. I am not a developer so when it will be safe enough for me to test it?

[Help needed with porting] Applauncherd port for Fremantle - launch apps faster and more economically
 

Well, more borked version is already in meecolay, so it's really safe ;D

@mods: I cannot change the thread title. it should be

Re: [Help needed with porting] Applauncherd port for Fremantle - launch apps faster and more economically
 

Thank you so much. I will give a try

Re: [Announce] [Beta] Applauncher port for Fremantle - launch apps faster and more economically
 

Well, miracle! :) The example apps are working. Pushing to devel. Test deps are broken, I'm gonna take care of it soon. And you need to
manually. (Daemon mode not tested)

Re: [Announce] [Beta] Applauncher port for Fremantle - launch apps faster and more economically
 

That's great news. Thanks for your hardwork.

I have below doubts though:
1. As i know it should share lib among apps and make device running faster and smoother (let me know if i am wrong) but i don't notice any difference, whether it need to be started manually through some script after each restart or something?

2. After the above command it just showed blank screen and nothing more happed. do we need to keep that background window open and use device.

3. which example apps? does it share libs among specific apps only?

Re: [Announce] [Beta] Applauncher port for Fremantle - launch apps faster and more economically
 

Looks like applications need to be aware of applauncherd? Also isn't it quite useless in Fremantle? Single instance support is through DBus, Qt is used by few programs, but is shared library, etc?

http://harmattan-dev.nokia.com/docs/...html/main.html

Re: [Announce] [Beta] Applauncher port for Fremantle - launch apps faster and more economically
 

@kraker_abhy:
1. Well, from my experience it depends on usage: if you use only one app, then you won't benefit from applauncherd. But if all Qt and QML apps use it, then it'll be a great benefit.
2. you need to use invoker and the app needs to be linked with applauncherd (currently the only ones are the testapps - the best example is fala_qml_wl - with invoker it start blitz-fast ;) ) QML apps take ultra long to launch, it's why it's a good idea.
3. The terminal window is left there because it's an alpha stage (I can't change the title ;( ). I'll work on daemon mode and autostart later
4. applauncherd-testapps
@iceskateclog
5. Yes the app needs to be aware of applauncherd. But even now you can add simple commands like
. If the invoker fails (not installed, broken, whatever), then it'll be launched without it.
6. single instance is useless for menu, but useful for control-panel, useful for running apps with a script. Or can it be achieved with maemo-launcher?
7. Plain Qt is not that uncommon, QtDeclarative is indeed uncommon.
8. Exec booster is something else. It's for splash screen and single instance. And Qt devs should use the Qt booster.
9. Well, a gtk booster should be written someday :)

Re: [Announce] [Beta] Applauncher port for Fremantle - launch apps faster and more economically
 

The full featured qml apps still crash. Just add the qdeclarative-boostable flag to UserAgentTool to qmake. Via ebooster they run ok, so it's probably a qdeclarative booster problem.

Re: [Announce] [Beta] Applauncher port for Fremantle - launch apps faster and more economically
 

Great work marmistrz. It really makes the apps start faster.
Is there any way to use MDeclarativeCache when using subclassed qapplication or qdeclarativeview?
Is there a cached version of qwidget?

Re: [Announce] [Beta] Applauncher port for Fremantle - launch apps faster and more economically
 

Sorry, I did it 2 years ago, barely remember the details :) I gave it up due to the lack of interest.

Thus,

1. If you want to take care of the whole package and develop it further, I'll aid you whenever you ask. But I'm not planning to develop it further myself.
2. To support qwidget, you'd have to modify the library-helper.py and rebuild. Maybe some changes in a booster would have to be made but I doubt so. Building sometimes stalls, then you just have cancel it and start anew. This doesn't happen in the autobuilder, though.
3. I guess the C++ inheriting shouldn't prohibit it using MDeclarativeCache. But I really don't know.

Please overtake the development if you wish.