maemo.org - Talk
Page 1 of 5 1 23 Last »
Show 40 post(s) from this thread on one page

maemo.org - Talk (https://talk.maemo.org/index.php)
-   Applications (https://talk.maemo.org/forumdisplay.php?f=41)
-   -   Slide 2 Answer (https://talk.maemo.org/showthread.php?t=71002)

F2thaK 2011-03-14 00:06
Slide 2 Answer
 
I was very happy to see this appear in the repos, but its too early to work.

I think maybe the CSSU portrait messes it up, but the screen is all jumbled.

Cant wait for an update ! :D






e: version 0.1.4 released 18/4/11
http://www.youtube.com/watch?v=0-XQO0SGKeE

Veleno 2011-03-14 00:20
Re: Slide 2 Answer
 
Same for me, howerer this is a very good news :D

F2thaK 2011-03-23 05:11
Re: Slide 2 Answer
 
any progress on this MAG or ru too busy with CSSU?

ejasmudar 2011-03-23 05:45
Re: Slide 2 Answer
 
can anybody post a screenshot?

vkv.raju 2011-03-23 06:24
Re: Slide 2 Answer
 
I think Mohammad already said that he is going to work on the rotation issues.

I hope the next CSSU update gets this! And also the qt-mediaplayer (looks like the stock one but completely new & re-written by Mohammad). Did anyone try that yet?

F2thaK 2011-03-23 07:45
Re: Slide 2 Answer
 
Quote:
Originally Posted by ejasmudar (Post 973650)
can anybody post a screenshot?
its currently not in a usable state

MohammadAG 2011-03-23 10:11
Re: Slide 2 Answer
 
The fact that it worked like crap is a reason I didn't announce it :P

I'm pretty sure the slowdowns are Qt-related, a Gtk rewrite would be appreciated, it's basically a daemon that needs to listen to DBus, get the number from there (same signal), then show/hide accordingly.

Oh and you also have to set a flag on the window (well, dialog) so it pops on top of the stock dialog:
http://gitorious.org/slide2answer/sl...dow.cpp#line89

vi_ 2011-03-23 10:26
Re: Slide 2 Answer
 
Guys, just use a dbus-scripts script...

slide switch open--->answer call (dbus call)

arora.rohan 2011-03-23 11:02
Re: Slide 2 Answer
 
Quote:
Originally Posted by MohammadAG (Post 973767)
The fact that it worked like crap is a reason I didn't announce it :P

I'm pretty sure the slowdowns are Qt-related, a Gtk rewrite would be appreciated, it's basically a daemon that needs to listen to DBus, get the number from there (same signal), then show/hide accordingly.

Oh and you also have to set a flag on the window (well, dialog) so it pops on top of the stock dialog:
http://gitorious.org/slide2answer/sl...dow.cpp#line89

Can you include a feature with this that, the proximity sensor gets disabled when we get a call so that the screen is always lit up.. and we can slide..and dont have to worry about rejecting a call accidentally.. or is it already included??

sakya 2011-03-23 11:47
Re: Slide 2 Answer
 
Quote:
Originally Posted by MohammadAG (Post 973767)
I'm pretty sure the slowdowns are Qt-related
I was working on something similar before your project (using Qt), and cannot remember any slowdowns...
I stopped developing it when I saw your project.
This evening I'll recheck my code and see if it is still working... ;)

aanckar 2011-03-23 12:07
Re: Slide 2 Answer
 
Quote:
Originally Posted by arora.rohan (Post 973790)
Can you include a feature with this that, the proximity sensor gets disabled when we get a call so that the screen is always lit up.. and we can slide..and dont have to worry about rejecting a call accidentally.. or is it already included??
This would be highly, highly appreciated!

ejasmudar 2011-03-24 04:54
Re: Slide 2 Answer
 
Quote:
Originally Posted by arora.rohan (Post 973790)
Can you include a feature with this that, the proximity sensor gets disabled when we get a call so that the screen is always lit up.. and we can slide..and dont have to worry about rejecting a call accidentally.. or is it already included??
This will NEVER be implemented as in a Touch Screen device, this exactly is the purpose of the proximity sensor: to disable the screen while the proximity sensor is covered, eg while in pocket. If proximity sensor was disabled, when the phone rings, the screen would lit up and the buttons would get pressed automatically.

Also, your problem is not caused due to delayed proximity sensor. IMO, it is due to delayed drawing of UI elements on screens, possibly due to high CPU load.

arora.rohan 2011-03-24 06:03
Re: Slide 2 Answer
 
:-/ While the phone is ringing there is no use of Proximity sensor if you have a slide to answer..

Proximity can be enabled after we pick up the call..

Think :) !

also..due to proximity sensor the cpu has to work more..cause of its absurd behavior.

MohammadAG 2011-03-24 08:29
Re: Slide 2 Answer
 
Quote:
Originally Posted by sakya (Post 973805)
I was working on something similar before your project (using Qt), and cannot remember any slowdowns...
I stopped developing it when I saw your project.
This evening I'll recheck my code and see if it is still working... ;)
Actually, it is related, see fastsmsevo, they keyboard sometimes takes ages to show up.

And when you're getting a call, the load that the phone goes through for a reason I don't know of is a lot, so that doesn't help @ painting UI elements.

ndi 2011-03-24 12:02
Re: Slide 2 Answer
 
I am not a Linux person, but can't you lower the priority of the phone while doing what you do, so that it can be useful? And then restore when slid so we can actually talk.

Helmuth 2011-03-24 12:55
Re: Slide 2 Answer
 
Quote:
Originally Posted by ejasmudar (Post 974414)
This will NEVER be implemented as in a Touch Screen device, this exactly is the purpose of the proximity sensor: to disable the screen while the proximity sensor is covered, eg while in pocket. If proximity sensor was disabled, when the phone rings, the screen would lit up and the buttons would get pressed automatically.

Also, your problem is not caused due to delayed proximity sensor. IMO, it is due to delayed drawing of UI elements on screens, possibly due to high CPU load.
No, thats not true! The proximity sensor disables the screen as soon as you hold the phone near your face / ear.
The abuse to use it to lock the screen in the pocket is only a dirty workaround. If you want to use it for this case you will need at minimum 4 proximity sensors at each corner of the screen to ensure the screen is really not covered while pulling it somewhere out.
The delay was introduced because of this in the last fix. But it doesn't fix the main problem. The phone unlocks the touchscreen itself. And the proximity sensor is the only sensor signal the N900 is able to evaluate if it is a good moment to unlock or not.

There are very good reasons why iOS, Android und even Symbian are using slide to answer if the screen was locked before. The proximity sensor has a other purpose.

Please see the Bug report for additional informations: Bug 5982

ejasmudar 2011-03-24 14:45
Re: Slide 2 Answer
 
Helmuth, arora, you guys are right! I didnt think of the ios way. I've only been used to winmo and uiq prior to maemo. Both these used the same methodology as n900. I never really thought about slide to answer as a feature rather than an eye candy. Thanks for opening my eyes.

However, i was thinking why all my previous phones all behaved the same. Then i got it- they all have a resisitve screen-like the n900. So, if the screen is on, it basically means that touching with anything is registered. And do you know what happens when we simultaneously click two points on our screens? it registers as a 0 second infinite speed slide. So even if do have a slide-to-answer, the resistive screen might make this potentially un-useful.
What do you guys think?

arora.rohan 2011-03-24 17:18
Re: Slide 2 Answer
 
Chuck Norris would say :
(silence )

I would say :

Not as bad as the current scenario. :-/ at least i would be able to pick call under 5 secs.

EDIT : and the thing about sliding.. you've used slide to unlock screen of n900 a lot fo times i guess...try using it once...the best part is..even if you move your finger up and down after you've pressed on the slider once..it still registers as a sliding!
Try it! :)

sakya 2011-03-24 19:56
Re: Slide 2 Answer
 
Quote:
Originally Posted by MohammadAG (Post 974477)
Actually, it is related, see fastsmsevo, they keyboard sometimes takes ages to show up.

And when you're getting a call, the load that the phone goes through for a reason I don't know of is a lot, so that doesn't help @ painting UI elements.
You're right...I didn't remember the slowdown, but I tried my program now and it takes some seconds (4 or 5) to render the window...

Here's a screesnhot:
http://img141.imageshack.us/img141/4...1032420482.png

MohammadAG 2011-03-24 20:54
Re: Slide 2 Answer
 
Quote:
Originally Posted by sakya (Post 975015)
You're right...I didn't remember the slowdown, but I tried my program now and it takes some seconds (4 or 5) to render the window...

Here's a screesnhot:
http://img141.imageshack.us/img141/4...1032420482.png
Yes, and when you're testing you're probably not doing anything else, while in practice, you'll probably have some load on the device, so that 4-5s gets bumped to 10-15 :)

This needs to be done in Gtk.

Helmuth 2011-03-24 20:56
Re: Slide 2 Answer
 
Quote:
Originally Posted by ejasmudar (Post 974729)
I never really thought about slide to answer as a feature rather than an eye candy. Thanks for opening my eyes.
Thanks for fast understanding. :)

Quote:
Originally Posted by ejasmudar (Post 974729)
And do you know what happens when we simultaneously click two points on our screens? it registers as a 0 second infinite speed slide. So even if do have a slide-to-answer, the resistive screen might make this potentially un-useful.
What do you guys think?
Mmmh... I would say that's half true.
Test it at a scetch application... If you put your finger on the right side of the screen and after that put your second on the left. The dot accelerate really fast, but stops exactly between your 2 fingers.

But yes, if you release your right finger now before the left the dot reachs the left side really fast.

I don't know how serious this could get. Perhaps yes, perhaps no. Perhaps we could filter it and recognize only "slow" slides... or slides that passes 5 points on the slide line and not only 3...
But anyway, it will improve the current problems.

And the next thing to think about:
The Nokia 5800 has also a resistive screen. This device had also Buttons to answer a call first and Nokia changed this behavior to slide to answer with a firmwareupdate.
I'm not sure, but I guess it was soon after the N97 got this update and slide to answer. But I don't know the facts exactly.
Anyway, I'm sure they had some reasons why they changed it! ;)

sakya 2011-03-24 21:21
Re: Slide 2 Answer
 
Quote:
Originally Posted by MohammadAG (Post 975062)
This needs to be done in Gtk.
The "strange" thing is that I pre-instantiate the window and only show it when the call arrives, so that time is only used to render the window (and retrieve a single contact with QtMobility to get name and thumbnail).
If Gtk is a lot faster...Qt needs some tuning... ;)

MohammadAG 2011-03-24 22:22
Re: Slide 2 Answer
 
Quote:
Originally Posted by sakya (Post 975087)
The "strange" thing is that I pre-instantiate the window and only show it when the call arrives, so that time is only used to render the window (and retrieve a single contact with QtMobility to get name and thumbnail).
If Gtk is a lot faster...Qt needs some tuning... ;)
Well, my implementation doesn't even get the contact avatar or name, so yes, it's painting that's slow.

You can see this when rotating a Qt app, it takes some time to reposition the widgets, while Gtk apps do it quickly during the rotation transition.

dov 2011-03-24 22:45
Re: Slide 2 Answer
 
I misunderstood this feature when I read it and thought that it was talking about sliding open the camera cover in order to answer the phone. But that might actually be a good idea! I.e. if the phone is ringing and the camera cover is toggled from closed to opened, then pick up the phone.

blipnl 2011-03-24 22:53
Re: Slide 2 Answer
 
Hey, but I've been perfectly able to answer calls on the N900 with slide to unlock already with the likes of NitDroid! Oh wait.. ehm.. well kinda


:D

arora.rohan 2011-03-25 05:44
Re: Slide 2 Answer
 
Must you hijack this thread with trolling?

ejasmudar 2011-03-25 05:55
Re: Slide 2 Answer
 
Quote:
Originally Posted by Helmuth (Post 975066)
Thanks for fast understanding. :)


Mmmh... I would say that's half true.
Test it at a scetch application... If you put your finger on the right side of the screen and after that put your second on the left. The dot accelerate really fast, but stops exactly between your 2 fingers.

But yes, if you release your right finger now before the left the dot reachs the left side really fast.

I don't know how serious this could get. Perhaps yes, perhaps no. Perhaps we could filter it and recognize only "slow" slides... or slides that passes 5 points on the slide line and not only 3...
But anyway, it will improve the current problems.

And the next thing to think about:
The Nokia 5800 has also a resistive screen. This device had also Buttons to answer a call first and Nokia changed this behavior to slide to answer with a firmwareupdate.
I'm not sure, but I guess it was soon after the N97 got this update and slide to answer. But I don't know the facts exactly.
Anyway, I'm sure they had some reasons why they changed it! ;)
Yes, it can be solved with a more complex sliding, rather than the usual linear sliding. But, as I understand from MAG and sakya, it is more a problem of UI drawing and disabling proximity sensor wont solve that.

arora.rohan 2011-03-25 06:01
Re: Slide 2 Answer
 
I would even be happy if i have slide to answer in Landscape mode. :-/

nicolai 2011-03-26 10:19
Re: Slide 2 Answer
 
2 Attachment(s)
Quote:
Originally Posted by MohammadAG (Post 973767)
I'm pretty sure the slowdowns are Qt-related, a Gtk rewrite would be appreciated, it's basically a daemon that needs to listen to DBus, get the number from there (same signal), then show/hide accordingly.
Yes, GTK is faster. The GTK-rewrite part was the easier part.
The challange was to support skype calls as well. I don't know
if I did it the right way, but it works. Many other developer
tried and searched for a way to accept/reject skype calls,
and didn't find an answer, so at the beginning I didn't
know if it would be possible at all.
But finally I found a way.

-the code is ugly
-the UI is ugly
-skype call handling only works if your are already connected
when starting this*.
- needs much more testing.
- no rotation support

I would be happy when someone can take over this project,
as I don't have the time to develop this further.

[*] This is a statusbarplugin, so you have to connect to skype
and then restart hildon-status-menu.
It isn't that difficult to listen to connection changes and register
the listener, so that this works even after connecting/disconnecting
to skype. I was just to lazy to do it the proper way.

Nicolai

F2thaK 2011-03-26 10:21
Re: Slide 2 Answer
 
damn wish this was a deb!

looks great, would love to test

daperl 2011-03-26 11:26
Re: Slide 2 Answer
 
1 Attachment(s)
Your wish is my command:

Code:
dpkg-buildpackage -b -d -nc
Be sure to let us know how it works.

daperl 2011-03-26 11:40
Re: Slide 2 Answer
 
@nicolai

I think there's something wrong with your debian/rules file. I had to blow away the stamp files to get things to recompile. Or one of our clocks is off. Not sure.

CrckMc 2011-03-26 11:40
Re: Slide 2 Answer
 
works good but I have only tried normal calls

arora.rohan 2011-03-26 12:39
Re: Slide 2 Answer
 
This new package has proximity Disabled? can anyone confirm ?

Proximity disabled while receiving the call and enabled when call picked up!

hawaii 2011-03-26 15:46
Re: Slide 2 Answer
 
I'm beginning to think that the camera lens cover might be an extremely good option for some of us - aka ME.

1) Call comes in.
2). Disable touch input.
3). Answer call on camera slide open.
4). Hangup call on camera slide closed.

CrckMc 2011-03-26 15:53
Re: Slide 2 Answer
 
one bug i found is when someone calls who is not in contacts it will display the name of the last known caller.

this could lead to some confusion :)

F2thaK 2011-03-27 03:07
Re: Slide 2 Answer
 
is there a GUI ? just installed, going to reboot.

F2thaK 2011-03-28 01:59
Re: Slide 2 Answer
 
got an update today, but i preferred the version i had

arora.rohan 2011-03-28 10:29
Re: Slide 2 Answer
 
http://store.ovi.com/content/78926?

Is this for N900 or i just got fooled by ovi?

Edit : sad...this application just adds an avatar...not like the pic displayed there...just a small avatar .. sadness.

zdanee 2011-03-28 12:03
Re: Slide 2 Answer
 
Is this faster / more responsive than the standard GUI? I have less problems with lousy GUI design than extreme slowdowns with incoming calls while accessing the net. Killing browserd or anything that uses too much CPU would be acceptable to me in order to make the phone app more responsive... Probably it is possible as a D-bus script?


All times are GMT. The time now is 06:34.
Page 1 of 5 1 23 Last »
Show 40 post(s) from this thread on one page

vBulletin® Version 3.8.8