Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
Carsten Haitzler (The Rasterman)
raster at rasterman.com
Sat Oct 31 10:51:24 CET 2009
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
More information about the community
mailing list