GNOME Bugzilla – Bug 127784
stroking with pressure should ignore click threshold
Last modified: 2010-03-07 17:05:01 UTC
When stroking with a pressure sensitive input device (such as a wacom stylus) the click threshold should be ignored, or at least lowered a great deal. Most of my fine motor control is at the light end of the range, so pressure sensitvity would both have greater range, and be more useful if this were true. With the current system, the stroke starts when the click threshold is reached, at the pressure of the click threshold. However, this means that if the click threshold is .4, then the scale factor (for size adjustment, for example) ranges from .4 to 1.0, which is obviously not as useful as 0.0 to 1.0. This problem is exaggerated with color sensitivity attached to a gradient. I am strongly tempted to mark this as a bug, since pressure sensitivity is not very useful without this change (e.g. trying to actually paint or draw something is very difficult without having access to the more sensitive part of my pressure range). However, I won't complain if someone changes this to an enhacement.
What makes you think there is something like a "click threshold"? If testinput receives pressure from 0.0-1.0, there is no reason GIMP should not get the same range. If the coords from the GdkEvent don't end up in a pressure range from 0.0-1.0 in paint_core->curr_coords.pressure, there must be else broken IMHO.
A possible solution for this would be to add a way to configure a pressure mapping. This is frequently requested and shouldn't be hard to implement. Isn't there a bug report for this already?
It's bug 50638.
Well, I don't think that is the same bug. There is a click threshold, because I need to press hard enough on the tablet for it to send an X click event. It is configurable in the driver as "Threshold" While gdk does send 0.0 to 1.0 as pressures, no stoke occurs unless I press harder than that threshold to activate a left click, hench, The GIMP doesn't actually _use_ those lower thresholds for anything. My point is that it should.
I meant the bug Sven was searching for, not this one. And how can you claim that you get ranges from 0.0-1.0 if you never get the events lower than your threshold? Or did I misunderstand your latest comment?
It's an assumption from looking at testinput. Basically, the stroking algorithm only activates once I have hit the threshold, so the threshold is the minimum pressure that the stroking algorithm ever uses.
How do you suggest we get to this value? I don't see a reasonable way to get to it.
Well, I think the only way would be to capture all motion events for the stylus and paint with them, not just the ones associated with a click. I think this should be done only for pressure sensitive tablets that have an "in" and "out" sense. I have no idea if the concept is supported in XInput or GTK. For example, wacdump reports an "IN_PROX" and a "DISTANCE" that actually report whether the stylus is actually touching the pad or not (since it will sense somewhat above the pad) and the distance the stylus is from the pad. (this is obviously useful for the airbrush input).
This isn't supported in GDK and we will certainly not change GIMP to draw outside a press and release event pair from GDK. You should get your driver fixed. It is supposed to return pressure values between 0 and some maximum value. If a threshold is set in the driver, the driver must remap so that for the slightest touch over the threshold, a value only slightly larger than 0 is generated. As this seems to be a driver issue, it should be closed NOTGNOME.
[re-submitting after collision with Sven's comment] I don't understand how you would like this to be used in practice, especially for those using the pen as a core pointer (no mouse). Let's say that you start painting something in the image window. How do you move the pen out of the window to access some of the other GIMP windows? It looks like it would not be possible to do this without leaving a trail in the image (because a low, but non-zero pressure may be reported if you are moving the pen just above the tablet). Wouldn't it be better to simply remap the range to [click threshold,max] instead of [0,max]? This is something that could be done with the lookup tables described in bug #50638 (in which case we should mark this as a duplicate) or it could also be done at the driver level (in which case we should close this as NOTGNOME).
All, well my tablet has a seperate number to describe proximity, which can be used to give a definate description of whether the stylus is touching (instead of just using pressure). However after talking in IRC, while what I want is possible, it would break the abstraction built up in GDK, so I would have to change some stuff in GDK first, then come back and implement this here. Basically what I want is the ability to have a different pressure threshold in the image drawing widget, than I have in the rest of my interface. Also, at the gimp level, GDK is suppose to provide a pressure range from 0 to 1.0, and while it does so, it does not map from 0 to 1.0 during a button press, and so pressure is not as useful as it could be in most situations. There are two arguments here to fix this. "It is a driver bug" One is that the driver should map its values from 0 to MAX (whatever MAX is, 1024 for me) and 0 should start at whatever is the click threshold before the mapping. I am not so sure I agree with this, because I think GDK should have as pure information as possible about the state of the device. If there is a bug, it is the driver not reporting the click threshold. "It is a GDK bug" The second argument is that GDK should query the driver for it's click threshold and do the mapping itself. I have no idea if XInput even reports the click threshold to GDK, so this might not be possible (see above about fixing the driver). I consider this preferable to "fixing" the driver because GDK does double math, and so the mapping would be more accurate. I also like the second argument, because I would like to have the click threshold configurable on a per widget basis in gdk, with the driver threshold acting as a default. If this were implemented in GDK, without changing the driver, then this feature could be implemented rather easily. I am going to start an enhacement request in GDK for this. I'd like to leave this bug open until I can hear back from the GDK people about implementing this.
The correct way to ask "the GDK people" for their opinion is to reassign the bug to GTK+/GDK.
oh, now he tells me. Reassigning.
Don't think there is any GTK+ component here. I agree with the reporter - the threshhold for painting should be lower than for interaction with GUI elements, and the simplest way of doing this is to implement it in the app. I suppose you could have gdk_window_set_click_threshold_for_device() or something, to set per-GdkWindow click thresholds, but that's a bit overcomplicated to me, and there is nothing that GDK can do that the app can't do as well. (In fact, GDK would *have* to simulate button press grabs, while the app could choose not to do that.)
*** Bug 127831 has been marked as a duplicate of this bug. ***
Owen, what about the other part? Should GDK report 0.0 to 1.0 during button presses? Currently, for my wacom, it produces threshold to 1.0 during button presses, which means I need to set my threshold to almost zero (zero causes spurious click events) in order for the stylus to be useful in the gimp. (and because of proximity, I can still control the mouse, I just can't touch the tablet at all without causing click events at all).
No, I don't think so. Making GTK+ report 0-1 during button press events would remove the ability for apps to do anything with sub-threshold values; you want light pressure when painting, and firmer pressure to activate GUI elements. Plus, GTK+ doesn't actually know where the threshold is, if I recall correctly. (though it's been a long time since I've looked at this.)
It seems this report asks for changing how extended input decives are handled by the paint tools. This is clearly an enhancement request.
Created attachment 132775 [details] bug apparent in Paint tool but not in Ink tool
I think that my previous attachment proves that this bug is not a problem with tablet drivers, nor with click threshold as even when click threshold is set to the lowest value possible the bug remains. It appears to be a problem with the paint and similar tools and the way they handle size pressure. Given that the ink tool works perfectly fine I am assuming it uses a different method. I know this is a rather old bug but it still needs to be fixed as it makes painting rather cumbersome.
Ian, if you want to help out with this, please redo your test with a recent checkout of the development version from the git repository.
I believe this "bug" was caused by the 1.2 prescale applied to pressure. This prescale is long gone from git and so I'm closing this bug.