On Sat, 31 Oct 2009 09:21:13 +0100 Matthias Huber <matthias.hu...@wollishausen.de> said:
> Carsten Haitzler (The Rasterman) schrieb: > > On Fri, 30 Oct 2009 19:47:27 +0100 Matthias Huber > > <matthias.hu...@wollishausen.de> said: > > > > > >> Laszlo KREKACS schrieb: > >> > >>>> To not confuse with window changing, I would suggest the following > >>>> scenario: > >>>> 1. double click for launching an app > >>>> > >>>> > >>>> why double click ? for me, i am using double click for a menu and a > >>>> single click for starting the app. > >>>> > >>>> > >>> Because when sliding, you can have accidental clicks. I know it from > >>> the hard way. > >>> (I came up a nice usability workaround in paroli exactly for this > >>> issue. It works good.) > >>> > >>> > >> yes i know this also from paroli. but it is solvable i think. > >> > >> openbox has a tunable parameter for distinguish between slide and click. > >> in my oppinion, this is highly usable. > >> > >> i personally find a single click more elegant and usable than double click. > >> > > > > the problem is not differentiating between slide and click - e and > > elementary have this too. it's that if you drag horizontally for example, > > your actual events often look something like: > > > > +----+ +--+ +--+ +-----+ + +-+ + +------+ + + + +---+ > > > that's exact what i told you, what openbox has: they say: if movement < > number_pixels then its click, > if movement >= pixels, its slide. and that's what i told you e and elementary have too. the problem is your finger moves the entire length of that line. the actual input events you see are the discontinuous stutters as above. see the "+" by itself? that's a press +release on the same spot. > in your case, one could hava a hysteresis over the time: if a single > click comes shortly after a slide, > it is part of slide. that's what i said... and it should be done in tslib/x - every toolkit and app should not have to go implement this again and again. the lower layers should sanitise input by the time it gets to x clients. > if you measure now the time of the tap, you have all you need for > differentiating between all this three events. > > generally i think, its better to get the btn-release instead of > btn-down. (from the view of windowmanager) > > and you are right: it should be done in tslib or window manager. well not wm. wm's dont intercept or modify events in any way. each x app (the wm, or the app listening to the events on the window where the events are going) gets them. so the choice is. 1. every toolkit+app does it (every game using sdl, every "GL" app (tho this is hypotherical - this is just the general case, not gta02), elementary, e, gtk, qt - they all need to repeat the same logic to filter these. elementary and e have logic to know the difference between a tap and a drag. the values are configurable and tunable. the problem is all the "dirty input". -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community