Notices

Hey, what You mean by "doesn't work very well"? For me (and bunch of other people) it's working flawlessly. Maybe it's more Your device side thing?

That's what I tried to explain. Thank you.

xdotools from repositories help achieve that. just remember to se it up to send right/middle click *on release* not on click itself, because it's not possible to emulate one` click while doing another. On release works pretty well, thought.

Proximity Sensor, every time it's polled, uses battery power. Since it's a basic rudimentary is-it-bright-enough-to-assume-I'm-open hardware piece, if you poll it at all often, you do get a slightly noticeable increase in battery drain.

So as nice as proximity sensor activation is - make it configurable. And, if the gesture detection is done RIGHT, this wouldn't ever be necessary. All the background gesture detection daemon SHOULD do is process screen events and report to the rest of the system (over DBus or something else if there's more efficient channels, idk) that gesture [gesture number/name/whatever] was detected.

Then applications should set up their own 'listeners' to such events, if they want to take advantage of specific gestures. You could, as part of the project, however, provide hildon-desktop/home patches to handle some of the gestures by default (I'm thinking swipes from bezel in either direction could be reserved for hildon-desktop, or at least up/down swipes). This would probably get CSSU'ed eventually if stable and good enough.

I would say the minimal requirement for gesture detection should be swipe-from-bezel from each side (and if you want to go that far, from the corners of the bezel; optionally from screen-into-bezel, or bezel-to-bezel, but be careful with the bezel stuff because, as I say below, there's no touch-sensitivity in the bezels afaik, so you'd really be watching for gestures that begin or end at the very EDGE of the screen, which could interfere with normal functionality, like dragging text selection with the mouse in MicroB to the edge of the screen to select more text than fits on the screen at once - so I personally vote against screen-to-bezel, though bezel-to-other-bezel would provide some more options for programs to use), and the clockwise/counterclockwise rotation. These gestures could then be used by any application, hildon-desktop/home included. As far as I understand such an implementation would be perfectly compatible with MicroB and the like using gesture detection for the same gestures, since those are built into the app UIs by Nokia. BUT, it means that now an open source recode of the MicroB UI could be more doable, because you can pull the gesture detection from the system-wide daemon once that's out instead of writing an in-app one.

Keep in mind that N900's screen bezel isn't touch-sensitive, so the swipe-from-bezel gestures would register as swipe-from-the-very-very-edge-part-of-the-screen-in.

But I'm rambling, back to replying to stuff:I still say that should be configurable and off by default, because properly done system-wide gesture detection wouldn't interfere with normal use, if you didn't try to feature-bloat it with gestures that are too similar to other hypothetical movements. The program you're in would retain normal functionality UNLESS it was patched to use one of the gestures. So drawing a spiral in MyPaint wouldn't trigger clockwise-circle-gesture events unless MyPaint had code to do something on that gesture. You can watch what app is in focus, and only send that app and white-listed system 'programs' like hildon-desktop/hildon-home the events (or don't white-list it, but let programs register over either the system or session bus for dbus depending on if they want to detect gestures when not in focus). OR you can expect the apps to incorporate checking if they are in-focus before using the gesture, which I think would be the easier and more flexible approach, though developers would have to be informed accordingly. Either way, you don't handle any of the RESULTS of the gestures from the gesture daemon - the gesture daemon should ONLY handle the gesture detection and event announcing over DBus or other interface.

In turn, if you incorporate some of the gestures into system-wide UI functionality, e.g. having hildon-desktop detect a swipe-up-from-bottom-bezel and return you to the task switcher, to use the WebOS/BB Playbook gesture example, it should be something you are very confident wouldn't get triggered during regular use of an app - so swipe-up-from-bezel would be one such example, swipe-down-into-bezel or figure-8-swirl (if you have such gestures) would not be.

Problem is, there are flaws even that way. If you make two touches instantaneously, it'll still think there's one touch, or if you make two touches right after each other, it would easily interpret that as a multi-touch gesture (with the center being the second real touch) because now the algorithm goes touch a was here, then it suddenly jumped to touch b, which leads me to conclude there's a touch at touch a and a second touch c which is calculated from those two touches. Where-as in reality all you did was have very fast clicking going on.

Something like it is doable, but it would be messy. Most of the code would probably be complicated extra 'error handling' trying to guess-work out which touches where consecutive and which were multiple.

This is something I wouldn't mind getting into since I'm slightly less incompetent at C now (read: I'm extremely incompetent, but extremely < completely). The general idea shouldn't be too hard, once you know how to get the screen inputs with C (I don't, though); then you just do some basic arithmetic on the coordinate of the touch after every change, and for more complicated gestures like swirls, you'd need to break out some fancy maths, but I have that buried in me somewhere from my calculus learning days.

OK I tested shortcutd again and it works

?

right with the battery drain, but I can't put it in hildon-desktop in a clean way (by now, in no way). I don't know how much power an application uses which tracks all movements all the time calculates, compares...
I would say you always need some trigger. As the desktop has only left/right swipes, it's easy to replace them. But pannable windows, games, text edditing needs a lot of black/whitelisting
Swipe from bezel is ugly .
If you can realize that academic stuff, you're welcome

Maybe you've proven me all wrong in your text, but please : shorter!

Sorry Sethka, but I can't agree with You. IMO, Mentalist did here brilliant job explaining things, and if you're too tired to read it now, get some sleep and try again. Because You better at least consider his suggestion, he wasn't sh*t talking, he really got a point there and You ignoring him will only bring You much frustration, if You decide to implement ideas not considering such useful feedback.

Some things just can be explained (on technical level, which, I think, is, or at least should be most appreciated here) in "shorter" way. And depreciating such effort is very rude from You.

At least, You can be sure, that he used more brainpower/energy to write it, that You can use to read thoroughly

Just my 2 bitcoincents...

Oh, I didn't want to sound rude, and yes it was time for sleeping, so sorry to Mentalist Traceur.

BUT I read it about four times and this
- "All the background gesture detection daemon SHOULD do is process screen events and report to the rest of the system (over DBus or something else if there's more efficient channels, idk) that gesture [gesture number/name/whatever] was detected" ...is far away from everything I can do. For me that's academic.
- "applications should set up their own 'listeners' to such events" ...this means the applications should be rewritten to work with gestures?
- "This would probably get CSSU'ed"... never ever will something I wrote get into CSSU as I can't really write clean applications.

"At least, You can be sure, that he used more brainpower/energy to write it, that You can use to read thoroughly"
I wouldn't bet on that ( A supernoob needs more brainpower than you to understand what you are explaining. And MT sure needed much less time for everything related to his post than me.
He seems to know a lot more than me, yes. But apart from that I was rude (what I didn't want to be yet again), where do you disagree?
Sure there are more intelligent solutions and if someone comes around to do it, I will happily step aside and shut up.
"he really got a point there"... please explain it to me.
Maybe you could say he overestimated my abilities. I even had to search what bezel is.
I don't want to sound rude now, I simply don't know what to do with MT's Post.

Can implementae "xdotools" for applications that do not support the mouse on the N900 react to your commands? For example, the N900's native browser

Sethka, Maybe you underestimate your abilities? See, the fact is, just by taking this initiative, your better than all of us mere idea guys. You're the one that is attempting to implement it. So dont depreciate yourself.

Secondly, I can see how MT's post can be overwhelming. What you can do is start off according to your abilities and own ideas and then changes can be implemented according to MT's post and other ideas. Don't worry, the greatest advantages to an open source project is the ability to collaborate.

Once you start something, the you can ask other experienced developers for help, invite patches, etc. The first step is often the hardest and loneliest.

Bon Chance.

Yes, it seems you are right. But it's the dumbest way to go (hope you didn't invent it).