0a60a9ecec1497e7cb4ae5c6e808b07874669d42
[expresskeys.git] / ChangeLog
1
2 _Version 0.3.1 1 Sep 2006_
3
4 * Graphire4 support. And what a chore it was! The task has revealed
5 weaknesses in the overall code structuring which _must_ be attended to.
6 So, a long time will pass on this end doing nothing but code refactoring.
7 Graphire4 got hacked in by some serious "spaghetti"...
8
9 OBSERVE: linuxwacom-0.7.5 or greater is _required_ for Graphire4 support!
10
11 In that release an option called GetTabletID was introduced (in xsetwacom
12 version 0.0.7), which gives us a reliable and future proof way of identifying
13 the tablet model any device belongs to (pad, stylus etc).
14
15 The function identify_device can be found in the exec_shell.c file, where
16 presently only Graphire4 as a family is registered. A finer grained division
17 is planned so that correct configuration files can be written out for the
18 Graphire4 BlueTooth, which lacks a Scroll Wheel, and the Intuos3 4x5 with
19 its single Touch Strip and 4 buttons.
20
21 Thanks go to Carsten Schurig for e-mail access to a real Graphire4.
22 Imagination and deducing can only produce the code, not verify it.
23
24 And, as a sidenote to the verifying part, the Scroll Wheel of a Graphire4
25 triggers button press/release events, (up = button 4, down = button 5) not
26 axis motion events as has been stated on the linuxwacom web pages.
27
28 * The -s switch to get status from a running program was added in the last
29 24 hours before the 0.3.0 release, without much thought. It turns out not
30 to be particularly useful in the intended manner. Standard error (stderr)
31 where it prints the report is private to each shell session. So if the
32 program already has been launched by one process, the next one who queries
33 from another shell will see nothing.
34
35 Therefore we now save a copy of the status output as a file as well in:
36 ~/.expresskeys/status.log The file gets created automatically at a daemon
37 launch (updated with each -s query) and is deleted by a normal program exit.
38
39 * Inform the user about the different values for a PressCurve, as chosen by
40 the wacomcpl program, already in the initial _configuration_ file. Nice to
41 have a copy nearby when doing manual editing.
42
43 * Implemented a rudimentary error handler (xerror_handler in on_error.c) for
44 Xserver error returns. It is mostly a cosmetic thing, but now we can save the
45 message in error.log as well. The downside is that some of the informative
46 text from an unhandled X 'crash' is lost, like exactly which function call
47 that was involved. This can of course be rectified with a more complete handler,
48 but then the exit_on_error function needs additional parametres, and all the
49 calls to it need adjustments... Some other day.
50
51 * Discover the real mode of a stylus at program start, instead of assuming it
52 to be Absolute.
53
54 * Fixed a bug where -d together with any of -h, -s, -r and -k would delete a
55 live PID-file.
56
57
58 _Version 0.3.0 27 Jul 2006_
59
60 * Finally and totally obliterated the src-expresskeysconf directory.
61 Such a tool will never be written by me. But there is hope balancing
62 on the horizon! At http://alavaliant.googlepages.com you'll find
63 "wacom-config", which is a pygtk (2.8+) point-and-click program for
64 configuration of the linuxwacom driver (through "xsetwacom") and
65 expresskeys version 0.2.x config file editing.
66
67 No more manual wrangling with "xprop" and "xev"! A future version
68 will support expresskeys 0.3.x (I've been assured).
69
70 * New configuration file (version 3), incompatible with version 2. The
71 reasoning around this switch can be read about in the USAGE file, ca
72 2/3 down under the heading "NEW in expresskeys version 0.3.0".
73
74 This will hopefully be the _last_ config file change that impacts the
75 user in a negative way. Future changes can be done non-destructively.
76
77 * New configuration _file name_. Depending on devices identified, either
78 a "padless.conf1" or an "intuos3.conf1" file is written out. Apart from
79 only containing relevant record fields, the headers of these files are
80 tagged with device "Identifier" strings from xorg.conf, like:
81
82 _intuos3.conf1_                         _padless.conf1_
83
84 ConfigVersion 3                         ConfigVersion 3
85 Identifier1Pad 1stIntuos3Pad            Identifier1Pad LACKING
86 Identifier1Sty 1stIntuos3Stylus1        Identifier1Sty Stylus1
87
88 The TODO file - better known as the "Wish-list" - hints towards why this
89 filename change has become desirable...
90
91 * Automatic detection and use of the first 'pad' and/or 'stylus' device found
92 through the XListInputDevices call. This happens unconditionally, but can be
93 overridden by specifically naming a device on the command line.
94
95 We still only allow one device of each kind (for now) so eg an automatically
96 picked stylus, say 1stIntuos3Stylus1, gets dropped if the user specifies the
97 1stIntuos3Stylus2 or a 2ndIntuos3Stylus1.
98
99 Anyone with a little programming understanding can change a copy of the code
100 in globals.c and alter the config_dir string to eg "/.expresskeys2". Then
101 that program copy can support another set of pad/stylus (until expresskeys
102 properly handles multi-devices).
103
104 * Expresskeys can now trace the stylus usage and automatically change
105 the pressure sensitivity (PressCurve) depending on which program window
106 that has focus. We call "xsetwacom" for the actual change, but the
107 implementation has minimal overhead - can't be felt or seen on my machine:
108
109 NOTE: To partially overcome a limitation in any Qt3 program (see the BUGS
110 file; they swallow all stylus button presses) we also have to judge the
111 state _every time_ the pen comes within operational height of the tablet,
112 aka ProximityIn.
113
114 1a) Stylusbutton - tip or rocker - pressed (doesn't matter which),
115 1b) or stylus reports itself as having entered proximity of the tablet.
116 2) Is the current focuswindow in our program list (plus "default")? = True.
117 3) Does the program name differ from the name in a historybuffer (1 back)?
118 4) Does the program presscurve differ from a historybuffer curve (1 back)?
119 5) Call xsetwacom only if these are true.
120
121 The above mentioned USAGE entry has all the important details.
122
123 So... now the program enters a more generic stage where it's beneficial
124 to any Wacom tablet user. Though, the name will remain expresskeys ;-)
125
126 * Deleted the old-extra directory with the small scripts for re-reading the
127 configuration file or terminating the program.
128
129 It is actually quite embarrassing, but the two options have been available
130 from _within_ the main_setup.c file since... forever. We already did a signal
131 send to check for a running daemon, so all it took was a slight rearrangement
132 and a few extra code lines. I _am_ myopic, but this oversight borders on
133 blindness.
134
135 It is now possible to do an "expresskeys -r" or "expresskeys -k" against
136 a daemon instance. (BLUSH)!
137
138 * A few more command line switches have been introduced:
139
140 -x sets -v and exits after some important info blocks.
141 -s tells a daemon instance to report status (info block).
142
143 The 'status' signal is triggered through SIGUSR2 (re-read of the config file
144 has always been linked with SIGUSR1). The information printed out by -s
145 is almost exactly how -x displays it during a non-daemon run. Difference
146 being that -s also gives the "OUR RUN-PID" field.
147
148 OBSERVE: If expresskeys is started from the "outside" by use of .xinitrc or
149 similar methods, the output of -s will be seen on that first text terminal
150 (most often back at "Ctrl-Alt-F1" when in X). To get visibility from a terminal
151 _inside_ X, first do an "expresskeys -k" then "expresskeys -d" and THEN the
152 "expresskeys -s" ;-)
153
154 * Finally remembered to give a warning about Gimp and the pad device.
155 The USAGE file has it as a top item, and I'll copy the text here:
156
157 "Important: Gimp doesn't know _anything_ about a "pad" device, so the option
158 File --> Preferences --> Input Devices --> Configure Extended Input Devices...
159 --> [Device: pad  Mode: Disabled] is how it should be set. If you change it
160 to Sceen or Window, pressing pad buttons or using touch strips will NOT work."
161
162 * Updated to a working email address in the AUTHORS file and removed the
163 obsolete private project page from README. The canonical page now is:
164
165 http://freshmeat.net/projects/wacomexpresskeys
166
167 It has been so since version 0.2.1, I just never got around to mentioning it.
168
169
170 _Version 0.2.6 25 Feb 2006_
171
172 * Continuation of the maintenance by future proofing the ./configure phase
173 of the program compilation. We now examine what is returned from the commands
174 "pkg-config --variable=libdir x11" and "pkg-config --variable=includedir x11"
175 which is used to identify a modular X11R7 release. If that fails, we fall
176 back on a hardcoded /usr/X11R6/lib[64] and /usr/X11R6/include path for the
177 monolithic X11R6 releases. Failing that... the users can specify their own
178 paths through the "--with-xlib=" and/or "--with-xinc=" options. ".
179
180
181 _Version 0.2.5 7 Feb 2006_
182
183 [Absolutely no new functionality! A pure maintenance release to prevent
184 trouble. Ticked off a todo-list based on user experiences and their snafus]
185
186 * Erased the useless code in the src-expresskeysconf directory. When or
187 if a graphical utility is written it should have a fresh start.
188
189 * Populated the auto-generated Gimp section of the configuration file
190 with a more complete set of keycodes (a collection which I use myself).
191 This was done in order to help people's understanding of the fields.
192
193 Updated the USAGE file with this Gimp information, close to the bottom,
194 since there was no easy way to auto-write a description in the configuration
195 file itself.
196
197 * Changed the expresskeys-reread.sh and expresskeys-terminate.sh scripts
198 in the old-extra directory so they won't use any hardcoded program paths,
199 except for the #!/bin/sh trigger. I thought that I had used the canonical
200 paths, but distributions apparently shuffle stuff around willy-nilly.
201
202 * Threw in a basic trap/filtering routine in config_read.c which silently
203 swallows illegal keycodes from the low region - below 9 [Escape] - unless
204 the program is run in verbose (-v) mode. Then it spits out a "keycode IGNORED"
205 message when the configuration file is read. Xlib crashes the program when
206 fed unsavory keycodes, so more work can be done in this area.
207
208 * Implemented a ./configure discovery section where a dummy file is
209 compiled and linked for each of libX11.so libXext.so libXi.so libXtst.so
210 X11/Xlib.h X11/Xutil.h X11/extensions/XInput.h and X11/extensions/XTest.h
211 Missing dependencies are thus quickly spotted and a comprehensible error
212 message delivered. A section dealing with dependencies has also been added
213 at the end of the INSTALL file.
214
215 The discovery section can be ogled in the configure.in file of the
216 root directory. I almost went mad before nailing a working piece like:
217
218 echo $'#include <X11/Xlib.h>\nmain(){}'|$CC -L$XLIBDIR -xc - -o dum 2>/dev/null
219 if test $? != 0 ; then
220    echo "Can not include <X11/Xlib.h> header file!"
221    SOMEERROR=1
222 else
223    echo "Xlib.h OK"
224 fi
225
226 So simple looking and yet so hard to produce...
227
228 * Included the following text block in the runtime help, the README and
229 the USAGE file (and now here ;-)
230
231 "Please direct any bug reports or questions to the top address in
232 the AUTHORS file. This program is _not_ a linuxwacom project."
233