Comment 2 for bug 780737

Note:

1. I have found this bug on a fresh, not used upgrade of Inkscape. During tests I did wiped out whole ~/config/inkscape folder to be sure there is no "dead" settings. I also inspected preferences.xml file looking for tablet specific settings which may be related to click/double-click/drag recognition. I did not found any.

2. I played a bit again with 0.47 to check how does the "click/drag threshold" setting affects mouse and how does it affect tablet.

 First this is not exactly true what I have written earlier. If this value is large it is easy to click on a segment of curve to select it (both adjacent nodes are selected). The double click inserts node. If this setting is zero doing the same requires exact accuracy. Normally if cursor is in a mode allowing selection of a segment and inserting a node it changes to a "hand". If "mouse-click/drag" threshold is zero, it just flickers when it is _exactly_ over the line segment. So in my opinion this option does not only control how to recognize click from drag but also controls "grab" ability when editing nodes. When moving objects (but not editing them) "grab sensitivity" seems to not control anything while "click/drag" do control how far one needs to move cursor to drag an object. But still, in node edit it also controls when cursor changes into a "hand".

The "click/drag threshold" set for mouse also applies to a tablet - when I do set it to zero (my hand+tablet has a 2..3 pixels jitter) it is impossible to do a thing with a path.

3. I did upgrade again to 0.48 and focused on nodes selection and "cursor changes to hand" case. To my surprise it worked as expected, till I killed all copies started prior the upgrade. After a clean restart of Inkscape the faulty behavior returned.

So I did change "click/drag threshold" to zero. This time even with a mouse I wasn't able to change cursor from arrow to hand when in node edit mode. So this is a first difference between 0.47 - 0.48. Then I tested if I can see any influence of "grab sensitivity" - as in 0.47 I can't see it. So I set "click/drag threshold" back to reasonable value.

When moving cursor with a tablet cursor do change to a hand the same way as with a mouse. With a single tap I'm able to select a path segment. I'm also able to drag it. But not to insert a point by double fast tap.
So the same way as in 0.47 the "click/drag threshold" does affect both mouse and tablet.

I moved to "Input devices" section. My tablet is a "Bamboo" with a pen only with tap, pressure and two buttons.. A generic driver reports however a plenty of other elements: eraser, finger and a set of buttons. I noticed however that all wacom elements are disabled. Well... I'm pretty sure I enabled them... Since I do not use pressure sensitivity I didn't notice any change in behavior. Ok, my wrong - I did enable a pen and verified that there was no pressure sensitivity earlier and now it is working.

It do NOT affect bug reported. In screen mode double tap still is not working. In window mode... well... I could not figure out how the heck window mode works - on my system in window mode cursor shown on screen is far off from the point when drawing takes place. It seems cursor is following screen mode while application assumes window mode. But it should not bother You since this is rather a driver error.

Ok, let's see what is in "input devices - hardware" dialog. When pen is enabled dialog nicely shows pen when I move it. Wacom driver reports idiotic 248 buttons count. Well.. But second from the left, fourth and fifth round lamp do lit correctly when I do press pen tip and manipulate pen buttons. The larger fields below round one are flickering. Hard to say what do they represent since there is no tooltips in this dialog.

Test if other places when double tap should be recognize are working. A double tap/double click should end Bezier curve creation. It works. So double tap itself is correctly recognized.

4.Cleaning ~/config/preferences.xml

No change - buggy behaviour is still present. So it is not #559140

5.Checking against #624277.

Save works for me IF and ONLY IF "save" button in "Input devices" dialog is clicked. It is not saved the same way as preferences are saved what may be misleading for users.

6. Looking for temporary workarounds.

 Ctrl-Alt+tap do insert node. With this work-around I can use 0.48. This is nice, since in 0.47 user defined pattern fills lead to frequent crashes.

With regards,
  Tomasz Sztejka.