Locked touchpad drags do not work on Lucid 10.04

[Steve Farthing]

Binary package hint: gpointing-device-settings

Enabling locked drags is an option presented by the GUI interface of this package for the Alps PS/2 Alps Glidepoint touchpad which this laptop has.

A locked drag is basically one and a half taps. One tap and then on the second tap, your finger remains on the touchpad without raising it. Hence, only one and a half taps. This should result in the same behavior as a left click-drag. But nothing happens.

Left click-drag works normally.

Package version: gpointing-device-settings 1.3.2-2

[Charlieb000 (charlieb000-deactivatedaccount)]

i have a Dell Studio 1737. and i am not sure if my discovery might help, normally its a finger-down-up-down-and move around operation, (a double tap and drag), but i found in ubuntu 10:04 that a triple tap and drag worked, finger-down-up-down-up-down-and move around. now i dont want to make a new bug report if this already is reported, but i dislike tripple tapping, i would like the normal double tapping. thank you.

[Charlieb000 (charlieb000-deactivatedaccount)]

my method doesnt work very well with moving windows around the screen (it maximises them instead after a delay after i lift up my finger - the cursor is be elsewhere on the screen, not on the title bar), but does work with selecting text and moving scroll bars.

if this doesnt effect an earlier version of UBUNTU i might switch to that.

[Charlieb000 (charlieb000-deactivatedaccount)]

the system i did the above comments on is using the 64bit OS (with ATI Propy drivers installed) i tried a 32bit live CD on the same system and it is exactly the same EXCEPT that i CAN move the windows around using the NORMAL finger motion for click-drag (down-up-down-movearound) the other one (down-up-down-up-down-movearound) is still required for resizing windows, scrollbars, selecting text.

[Charlieb000 (charlieb000-deactivatedaccount)]

there is no delay on the 32bit version either -- maximise is immediate (even trying the 3 click version), both are 10.04, LL.

after going back to the 64bit OS (after restarting from the LiveCD which rebooted the machine), moving windows around seemed to work NORMAL, after shutting down, and restart it worked normal. the delay still exists when maximising. then i did some more mouse work while waiting for Natty to download and found out how this bug actually works! what you need to do is be VERY active (fast) just before doing the double click, if you dawdle then it will not register a double click. so move around fast around the screen prior to doing it.

during the delay on the 64bit OS, i cannot select other windows - proving a temporary hang. usually it did register a applications menu click when it came back.

CB.

[Charlieb000 (charlieb000-deactivatedaccount)]

i am thinking of making another bug because the title doesnt adequately describe the situation (slow motion on touchpad prevents drag-clicking from working), i am not changing incase my solution doesnt work for steve and i would be hijacking his bug.

[Charlieb000 (charlieb000-deactivatedaccount)]

my touchpad is a "AlpsPS/2", "ALPS GlidePoint"

[Charlieb000 (charlieb000-deactivatedaccount)]

i discovered it is the other way around, the drag motion must be at first fast (rather than fast motion before)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[positivek (anonyhole)]

I have Xubuntu, 12.04 (precise), running on a Sony Vaio VGN-NW230G, with Alps PS/2 GlidePoint. Using the touchpad only.

The 1.5 tap to drag works *only* when there is *motion* during the second tap, but does *not* work when you do an in-place (no motion) 1.5 tap. The 2.5 tap in-place and with-motion does work, however. Summary I've found is below.

PROBLEM: Use case #3 should be handled if case #1 is handled. So, if you solve case #1, case #3 remain working. Case #1 is very important for any graphics work, as well as gaming, or even simple window management. Case #1 is the easiest of the tap-to-drag motions, but is the one that is not working.

CASE #1:
1.5 tap in-place means: finger-down, finger-up, finger-down (no horiz/vert motion in finger during the finger-down).

  - BUG: This does not register at all (like nothing happened). Use case is where you want to move a graphic item by some small amount from it's current position. You should be able to initiate the drag ("locked drag"?) without any motion, and then start dragging after the object has been "grabbed". Currently I cannot.

CASE #2:
2.5 tap in-place means: finger-down, finger-up, finger-down, finger-up, finger-down (no horiz/vert motion in finger during the finger-down).

 - OK: This works. Use case is where you want to select text by whole words.

CASE #3:
1.5 tap with-motion means: finger-down, finger-up, slide-finger (with horiz/vert motion during finger-down).

 - OK: This works. Use case is same as case #1, except that the user is hurrying or does not care about small relative position change for dragged item.

CASE #4:
2.5 tap with-motion means: finger-down, finger-up, finger-down, finger-up, slide-finger (with horiz/vert motion during finger-down).

 - OK: This works. Use case is same as #2, but more rushed.

[Andreas Moog (ampelbein)]

This package has been removed from the Ubuntu development release, so I am closing all remaining open bug reports.

Sorry that we couldn't fix your problem properly, but gpointing-device-settings is dead upstream, buggy and completely unmaintained.

For more information, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870961

Thank you for your understanding and please continue to report any bugs you may find.