version 0.3.1
[expresskeys.git] / BUGS
1
2 _NOTABUG_
3
4 Any program built with the Qt3 toolkit (like eg the KDE desktop...)
5 completely swallows the 'stylus' DeviceButtonPress event that we've
6 registered to be notified of, through the Xlib XSelectExtensionEvent
7 call. The same event coming from the 'pad' device is all OK, though.
8
9 This is a (deliberate?) Qt pattern where only other Qt programs,
10 with difficulty, can get deliverance of these low-level events. At
11 least that's my impression after a first round of bug-report emails
12 between here and there --> Qt producer company Trolltech.
13
14 Why they let 'pad' button events pass through is probably due to lack
15 of knowledge. They recognize an oldtimer like the 'stylus', so BAM,
16 grab it. But this strange 'pad' thing... better stay out of contact...
17
18 Programs based on the GTK+ toolkit like the Gnome desktop (with the
19 notable exception being the Gimp canvas - more about that below) do
20 behave appropriate vis-a-vis both the 'stylus' and 'pad' button events.
21
22 This situation has led to one design compromise (performance slippage)
23 in expresskeys 0.3.0, and a not wholly ideal usability pattern when
24 dealing with Qt3 programs.
25
26 Performance wise we take a hit by also registering for and acting on
27 a 'stylus' ProximityIn event. These events are not blocked by Qt3.
28
29 Execution of the "automatic change of stylus pressure sensitivity"
30 in a Qt3 program is achieved by first lifting the pen slightly (until
31 it goes out of proximity - the cursor stops being effected by pen
32 movement) and then lowering the pen again on the target window.
33
34 If we happen to be in Gnome, it is enough to touch the Qt3 program on
35 the titlebar or on its other borders (since they are GTK+ derived).
36
37 GTK+ based programs suffer no such limitation. In those we just press
38 the pen tip in the window, and by that action the pressure sensitivity
39 change is performed. Unless the target is the Gimp canvas (at least as
40 high as version 2.2.10)...
41
42 The Gimp canvas is even _more_ broken (in regards to our expectations)
43 than the Qt3 programs. Here both the 'stylus' DeviceButtonPress AND
44 the ProximityIn events are filtered away from interested parties.
45
46 So in order to get the automatic change of stylus pressure sensitivity
47 when coming in from another program window, the pen tip or side button
48 rocker first must engage _somwhere else_ than the canvas. Just touching
49 the Gimp titlebar or touching an area outside of the canvas will work.
50
51 If we happen to be in KDE while using Gimp, then a simple titlebar
52 touch won't work (all the borders are Qt3 derived). Here we must do the
53 proximity out/in trick on a part not being the canvas, or touch
54 somewhere else than the window borders/Gimp canvas.
55
56 Phew. But there's a mitigating factor to all this Qt3/Gimp canvas
57 mess. We can use the "non-trigger" to our advantage.
58
59 For example, I normally like the PressCurve to be "0 25 75 100"
60 (sensitivity 3) in Gimp. But sometimes I'd like it to be a bit firmer.
61 So if the root window (the "background" in X) or some other window
62 nearby is set to sensitivity 4, it is a quick touch operation away to
63 either stay with a level 3, or switch to a level 4 while painting.
64
65 _Known bugs marked with FIXME in the code_
66
67 ! Parsing of the configuration file still leaves some corner cases
68 to chance.
69
70 It doesn't handle situations where multiple fields are specified
71 on the same line. Possibly other cases, see the FIXME markers.
72
73 ! The exit_on_error function drops the EXIT_KO when callig
74 clean_up_exit. It becomes a normal EXIT_OK signal for any controlling
75 parent.
76
77 ! Should check that only valid keycodes (and our fake ones) are used
78 in a program definition. It is only partially fixed by filtering out
79 anything below the keycode 9 [Esc]. Should ignore erroneous spaces in
80 the class name field.
81
82 _Possible bugs, unmarked_
83
84 ! In eg Gimp, if expresskeys is started with the option to handle a pen,
85 my core pointer (an USB mouse) and the Wacom puck do not draw through
86 button 1 or react to mouse button 2 and 3 presses until the Wacom stylus
87 has come into proximity for the first time. After the first proximity,
88 the mouse and puck react normally. Strange...
89
90 ! If the expresskeys program is started before any usage of the
91 X program "xmodmap" in eg .xinitrc, it can crash with the message:
92
93 X Error of failed request:  BadWindow (invalid Window parameter)
94   Major opcode of failed request:  15 (X_QueryTree)
95   Resource id in failed request:  0x1
96   Serial number of failed request:  20
97   Current serial number in output stream:  20
98
99 Reason, totally unknown...
100
101 _Known bugs, unmarked_
102
103 ! Pressing a pad button with one program window in focus, moving the
104 focus to another program window and then releasing the button, leaves
105 the first program in a confused mind regarding the keyboard state.
106 Returning the focus and pressing the button again (or another that
107 has an effect) restores the sanity.
108