* add support to Wacom Cintiq 20WSX
[expresskeys.git] / BUGS
1
2 _Known bugs marked with FIXME in the code_
3
4 ! Return errors are not caught from the system(3) call, only straight errors
5 (e.g. fork() failed). So we never actually know if xsetwacom did its job
6 properly when changing stylus PressCurve or doing tablet Rotate.
7
8 _Known bugs, unmarked_
9
10 ! Pressing a pad button with one program window in focus, moving the focus to
11 another program window and then releasing the button, probably leaves the first
12 program in a confused mind regarding the keyboard state. Returning the focus and
13 pressing the button again (or another that has an effect) restores the sanity.
14
15 _NOTABUG_
16
17 [NOTE: The story below was written when I only owned an Intuos3 tablet. Having
18 bought a Graphire4, I was pleased/shocked to see the stylus behaving _perfectly_
19 even with Qt-based programs! Both ButtonPress and ProximityIn/Out were
20 propagated through the Xlib environment exactly as they should. Could there be
21 a bug in the linuxwacom drivers instead of one in Qt? Had I judged too quickly?
22
23 Asking a Volito2 owner (who also happens to be a skilled programmer) about the
24 stylus-issue did not clear the waters... ButtonPress was swallowed in KDE,
25 just like it was for my Intuos3. Furthermore, _ProximityOut_ never became
26 visible on his system.
27
28 Comparing debug output from the linuxwacom X driver, for Volito2/Graphire4
29 /Intuos3, showed them to be almost identical when it came to events. The driver
30 correctly hands X everything it should get.
31
32 I must admit to being totally confused at this point in time. Why the striking
33 differences between tablet models? Why Qt and not GTK+? Why, for heavens sake,
34 even a ProximityIn/Out discrepancy?
35
36 So, take what you read below with a grain of salt. Blame-wise I could be
37 barking up the wrong alley. In that case, Mea Culpa. Pardon etc etc :END NOTE]
38
39 --Begin Original Text--
40
41 Any program built with the Qt3 toolkit (like eg the KDE desktop...)
42 completely swallows the 'stylus' DeviceButtonPress event that we've
43 registered to be notified of, through the Xlib XSelectExtensionEvent
44 call. The same event coming from the 'pad' device is all OK, though.
45
46 This is a (deliberate?) Qt pattern where only other Qt programs,
47 with difficulty, can get deliverance of these low-level events. At
48 least that's my impression after a first round of bug-report emails
49 between here and there --> Qt producer company Trolltech.
50
51 Why they let 'pad' button events pass through is probably due to lack
52 of knowledge. They recognize an oldtimer like the 'stylus', so BAM,
53 grab it. But this strange 'pad' thing... better stay out of contact...
54
55 Programs based on the GTK+ toolkit like the Gnome desktop (with the
56 notable exception being the Gimp canvas - more about that below) do
57 behave appropriate vis-a-vis both the 'stylus' and 'pad' button events.
58
59 This situation has led to one design compromise (performance slippage)
60 in expresskeys 0.3.0, and a not wholly ideal usability pattern when
61 dealing with Qt3 programs.
62
63 Performance wise we take a hit by also registering for and acting on
64 a 'stylus' ProximityIn event. These events are not blocked by Qt3.
65
66 Execution of the "automatic change of stylus pressure sensitivity"
67 in a Qt3 program is achieved by first lifting the pen slightly (until
68 it goes out of proximity - the cursor stops being effected by pen
69 movement) and then lowering the pen again on the target window.
70
71 If we happen to be in Gnome, it is enough to touch the Qt3 program on
72 the titlebar or on its other borders (since they are GTK+ derived).
73
74 GTK+ based programs suffer no such limitation. In those we just press
75 the pen tip in the window, and by that action the pressure sensitivity
76 change is performed. Unless the target is the Gimp canvas (at least as
77 high as version 2.2.13)...
78
79 The Gimp canvas is even _more_ broken (in regards to our expectations)
80 than the Qt3 programs. Here both the 'stylus' DeviceButtonPress AND
81 the ProximityIn events are filtered away from interested parties.
82
83 So in order to get the automatic change of stylus pressure sensitivity
84 when coming in from another program window, the pen tip or side button
85 rocker first must engage _somwhere else_ than the canvas. Just touching
86 the Gimp titlebar or touching an area outside of the canvas will work.
87
88 If we happen to be in KDE while using Gimp, then a simple titlebar
89 touch won't work (all the borders are Qt3 derived). Here we must do the
90 proximity out/in trick on a part not being the canvas, or touch
91 somewhere else than the window borders/Gimp canvas.
92
93 [A paragraph with faulty logic was deleted. Ed.]
94
95 --End Original Text--
96