On Fri, 4 Sep 2009 09:46:01 -0700 Dima Kogan <dko...@cds.caltech.edu> said:
> Hi Raster. > > I'm not quite as careless as you seem to think. The X patch allows for > both dragging and mousewheel scrolling, depending on the dynamics of > the motion (for details, see the post linked in the original email > below). Dragging, using drawing apps, etc, are still possible. In the > current implementation, mousewheel scrolling is easier to trigger, so > anybody who uses a lot of apps with dragging motions would get mildly > annoyed. As such, I don't consider the X patch ready to go upstream > yet; there really needs to be a switch to disable the new behavior. > > The purpose for this patch is to add finger-scrolling support for > a huge number of applications already out there. I can now scroll my > browser without needing to aim for the scrollbar. If you ask me, > implementing the scrolling-as-dragging behavior on the application > level is silly, and really belongs in the mouse driver. In either case, > the patch to the illume keyboard is fairly innocuous. I don't think > anybody who has a real wheel-mouse attached to their device is likely > to be using a soft keyboard. Thoughts? well - the fact you had to patch illume is an indicator that your x patches are bad. it has affected an app. again - a lot of classes of apps will be affected and no longer work correctly in some or many cases without patches. even with the patch to x - your dragging doesn't resemble/track the actual dragging of the user. ie i drag my finger up 1/2 a screen - does the content also come up 1/2? no. if it does it's a lucky coincidence. it's a hack that is invasive to application behavior. i'm actually doing this stuff with real products and applications cease to work. i'd have to patch a tonne of code. yes - click quick swipe and release (not pause for 200ms) isn't a normal usage pattern for sliding a slider or scrolling. literally it is desired and must drag WITH the finger and even at edges of an area. as i said - games will suffer badly from this. and i can't see your x patches (not accessible) but how do u handle hysteresis for the "hold for 200ms and not move?" does it literally have to not move or move less than X pixels. how are those X pixels set if so? what if screen resolution changes thus input resolution changes? not to mention handling things like cancelling the current click+release "action" when it is "broken" by a drag that is far enough to be considered one other than input jitter. a lot of this needs to be handled at a higher level that x can't. it doesn't know if an area is scrollable or not or it's a game that wants u to drag around to change your view direction and tap to "fire" or whatever. not to mention momentum handling for "swipe". this requires getting coordinates over time to figure out velocity and direction then make it continue. i've been doing this for a while now and i am relatively sure you'll get similar comments from upstream. from other toolkit and application developers too. if it was me upstream i'd be denying the x patch because it is the wrong way to do this. it is invasive to application behavior as in it breaks apps that ACTUALLY are written to handle touchscreens. and trust me there ae ones that are and toolkits are too. those not written to handle it likely will get support at some stage. it thwarts the ability to make things better. for apps to handle a touchscreen properly. it isn't a harmless "support legacy apps and dont affect those trying to do better". when mousewheel support was added to x as buttons 4/5 and so on - this was the case. it's non invasive. apps eventually adapted to it. i remember the days before toolkits and apps supported a mousewheel. i can say from your description at least it will break scrolling behavior in elementary as well as toggles and sliders will not work as well(requiring the pause then drag). instead of patching x - patch the major toolkits. the patch is in the wrong spot :( i know this doesn't make you happy - but there are times i can't say yes. this patch is for behavior that i think is wrong. it complicates the code with logic i don't think will ever be in "real life" use - it adds handling for something i don't see will make it upstream, and i think is being done in the wrong place, thus requires patches and fixes already to apps one way or another to work around the patch side-effects. instead of working around the side-effects with patches - just make the behavior of the other toolkits work with finger dragging. chances are that the other toolkits will get this as a native feature some time in the future anyway, thus obsoleting your patch, and obsoleting the changes to illume's kbd. : ( > dima > > On Fri, 4 Sep 2009 10:57:44 +1000 > Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: > > > On Fri, 10 Jul 2009 09:12:44 -0700 Dima Kogan > > <dko...@cds.caltech.edu> said: > > > > > Hi. > > > > > > I added support for touchscreen scrolling to kdrive and tslib-based > > > X servers. With that patch, screen dragging can generate mousewheel > > > events instead of dragging events. This behavior directly conflicts > > > with those parts of e that try to implement that > > > dragging-as-scrolling functionality in the application instead of > > > in the driver. I'm attaching a patch to support mouse-wheel events > > > in the illume keyboard. For the patch to the xserver (haven't sent > > > it upstream yet), see > > > > > > http://lists.shr-project.org/pipermail/shr-devel/2009-July/000251.html > > > > > > The new behavior is working very well for me, and I think this patch > > > should be included in the tree. > > > > hmm. such a x patch will conflict with every app that: > > > > 1. scrolls with a scrollbar > > 2. scrolls by dragging content > > 3. has a slider of some sort > > 4. drawing apps > > 5. handwriting recognition > > 6. games that use any dragging > > 7. drag and drop > > > > if you ask me... thats a pretty bad idea. it may work for the illume > > kbd, but a tonne of elementary, e itself and other apps and toolkits > > are broken now. why did you do this? it's a bit like throwing a > > nuclear bomb on your city to kill the cockroach under your fridge. :) > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" > > -------------- The Rasterman (Carsten Haitzler) > > ras...@rasterman.com > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
