I am curious are you using stock swap settings and some overclock?
I have OC up to 900Mhz and swappolube proposed settings, I have custom swap or use my SD card for big I/O but otherwise the above.
<OT>CSSU Thumb9, OC to 805MHz, SR on, Swappolube proposed settings, swap on SD.
Starting an app for the first time after a reboot takes ages (20-30 seconds for Leafpad, for example), closing it and starting it again is much faster. Camera is the biggest pain. It can take up to 2 minutes(!) to start and often freezes on taking a picture. I suspect an I/O contention between swap and DCIM on SD. Switching Camera to DCIM in MyDocs helps a bit.<OT>
I have only tested it on my current CSSU thumb version so I have no idea how it will behave in older versions but feel free to upload it to repo. Thanks.
Thanks for response pichlo. I have never compared speed between stock and my application. The main purpose was to avoid accidentally reject call and annoying rotation and it works quite good for me but as you can see doesn't have to work good for others. I hope that you rebooted your phone after installing the application.
I suspect that qslide answer is faster on many machines as it has no turn animation which is automatic and cant be disabled with the standard Maemo answer screen at least after the last Nokia update or perhaps CSSU.
Qslideanswer or previously a wired/BT headset were often the only way I got a chance to answer if I have a web browser or other app running.
Someone let us know when qslideanswer is up on the repos.
Since basic functionality is working now is there any further development or features planned?
The code is pretty compact which I think makes it so quick, not sure what else would even be desired without being bloat.
I have only tested it on my current CSSU thumb version so I have no idea how it will behave in older versions but feel free to upload it to repo. Thanks.
So send me the source tar.gz with debian packaging. The one on the OP has no packaging.
Another issue is that the qslideanswer screen is now staying up on screen blocking access to the desktop, even qtedgedger wont let me minimize the qslide answer screen. I answered using my BH-214 headset's answer button while the phone was in the pouch I discovered the problem when I herd the beep from a calendar reminder during a call, I had to slide the red reject thing to dismiss the stuck qslideanswer screen after completing the call.
biketool,
- first problem: Yes but I have no idea have to fix it for now - http://wiki.maemo.org/Phone_control#...ent_phone_call
- second: QSlideanswer has "_HILDON_STACKING_LAYER" set to 9 so you can't just bring hildon-desktop to top. This is what qtedger do with appMenu, taskMenu.. commands.
Probably I will add headphones support in next version but now I have a problem with upload privileges. I sent request few days ago but still have "You don't have rights to upload to extras or extras-devel at the moment". Does it still work?
Elros, of course waiting for the fixes/improvements but there is still IMHO nothing to compare to QSlideAnswer. For me so far it is a 100% reliable way to answer my phone without waiting for hardware accelerated rotation animation. Any other problems I have had are minor compared to missing calls because of the Maemo answer software bogging down when other apps are open.