maemo.org - Talk - Slide 2 Answer

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)

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! ;)

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... ;)

Re: Slide 2 Answer

Quote:

Originally Posted by sakya (Post 975087)

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.

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.

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

Re: Slide 2 Answer

Must you hijack this thread with trolling?

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.

Re: Slide 2 Answer

I would even be happy if i have slide to answer in Landscape mode. :-/

Re: Slide 2 Answer

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

Re: Slide 2 Answer

damn wish this was a deb!

looks great, would love to test