Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)

[Carsten Haitzler (The Rasterman)]

On Sat, 31 Oct 2009 09:21:13 +0100 Matthias Huber
<matthias.huber at wollishausen.de> said:

> Carsten Haitzler (The Rasterman) schrieb:
> > On Fri, 30 Oct 2009 19:47:27 +0100 Matthias Huber
> > <matthias.huber at 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)    raster at rasterman.com