Carsten Haitzler (The Rasterman)
raster at rasterman.com
Mon Apr 20 03:06:25 CEST 2009
On Sun, 19 Apr 2009 21:21:39 +0400 "Nikita V. Youshchenko" <yoush at debian.org>
> > i considered it but as i couldnt do "finger scrolling" (middle of the
> > window - swipe to scroll) i chose not to try and push the work back onto
> > the app to adapt to a limited window side.
> Theoretically it should be possible to implement "finger scrolling from the
> middle of the window" starting with some recognizable gesture.
> Althouht don't know how this could be done at technical level.
the problem is... it can't be done... unless:
1. you poll often (there goes battery life as you'll need to poll 10+ times a
second). you need to poll and query the mouse position/state. this is not an
acceptable solution for an embedded device if you care about battery life.
2. xevie - this is an event redirector extension. ALL mouse events can be put
through it. this will add an extra 2 context switches for an vent to get to the
app and go through such a redirector (eg the wm). xevie also gets little love
from the x developers.
other than this, it's not possible as ONLY the client that owns the window
a listens for events can get events on it. they are only reported to this
client (thanks to button grabs being implicit it). also you would need to
walk the entire window tree down from the client window AND monitor all changes
AND select for mouse events for all these windows AND still not get hem when you
press the screen as mouse vents will be reported to the grabbing owner - ie the
one that asked for mouse press and release events. so basically even afetr al
the pain of doing things you shouldnt (playing wit the internal window tree of
an app's window) it still wont work... so .. back to the above 2 methods - both
of which really are sub-optimal
> > in reality - apps should probably handle this themselves. i know e's
> > config dialogs mostly dont fit - but that is a todo item
> There is also everything else. Lots of X apps are not designed for small
> screen, and fixing all those looks like much more work than making it
> possible to access larger-than-screen windows. Btw, these two ways don't
> exclude each other :)
no they dont, but see above. its simply not sane to do it. i havent even
covered the conflicts of internal scrollbars, sliders etc. inside the apps -
now u cant drag those anymore if the window is too bit as it will scroll the
window, not move the scrollbar inside the window or the slider.
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster at rasterman.com
More information about the community