version 0.2.0
[expresskeys.git] / ChangeLog.1
1
2 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 Important: If you use the linuxwacom-0.6.7-beta or in the future
4 released versions you must change the pad statement in X config
5 file to:
6
7 Section "ServerLayout"
8 [...]
9 InputDevice "pad" # Intuos3 or Cintiq 21UX. It must NOT send core event
10 [...]
11 EndSection
12
13 See: http://linuxwacom.sourceforge.net/index.php/howto/srvlayout
14
15 If you use the old pad statement, any pad button press will jump the
16 mouse cursor to the upper left corner (0,0) when another tool isn't
17 in proximity.
18 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
19
20 Run example: expresskeys pad &
21 Which will push it into the background. It is safe to close the terminal
22 afterwards. Oh, and X _must_ be running... The name, "pad" here, is
23 how it's called in xorg.conf (the "Identifier" option).
24
25 Update example 17 March 2005: Myself I've put it in the .xinitrc as
26 "exec /usr/local/bin/expresskeys pad &" (without quotes) right before
27 the window manager is started.
28
29 Key configuration is easy to change in the "user config area" below.
30 Use the "xev" program to find keycodes or look them up somewhere...
31 I've set the Wacom Intuos3 defaults on both sides, which is:
32 Shift, Alt, Control and Space. Touch strips are mildly supported.
33
34 Note 2 April 2005: Sometimes desktops or window managers "steal"
35 certain keypresses/combinations. If you experience that, look for
36 a way to change the keybindings of your environment.
37
38 _Version 0.09 4 April 2005_
39
40 Bugfix to handle some weird windows who don't set the "class",
41 and even their parents lack it (like the "xev" program...). I
42 won't go further back in a hierarchy, so these weirdos get the
43 "default" keyset.
44
45 Note: Without this fix expresskeys will crash in such cases.
46
47 _Version 0.08 3 April 2005_
48
49 When I was customizing the keyboard shortcuts within Gimp itself
50 (I wanted Alt + and Alt - to do Next Brush and Previous Brush) it
51 became obvious that I couldn't assign these brush steppings to any
52 touch strip, due to my shortsightedness.
53
54 Now touch strips can send two keys at a time, just like the pad
55 buttons: l_touch_up, l_touch_up_plus etc. All of the "_plus" touch
56 strip definitions are set to 0 (nothing) per default.
57
58 Being able to use the touch strips for things like this is really
59 neat. Look in Gimp's File -> Preferences -> Interface -> Configure
60 Keyboard Shortcuts -> Context for some good touch strip candidates.
61
62 Bugfix: Would crash if _no_ window had focus (except the root win).
63
64 _Version 0.07 2 April 2005_
65
66 Multiple configurations to rule them all... Yes, we now send
67 keypresses intelligently based on several configurations. I've
68 included a "default" catch all type, one for Gimp, for Blender
69 and for XTerm. Observe the spelling! It is case sensitive.
70
71 To create a new definition, just copy a full block and alter the
72 Name and the keycodes. To find the proper name of a program/window
73 fire up "xprop". It should be included with your X. xprop without
74 any arguments expects you to then click on the target window.
75 What comes out is a flood of information in the terminal window
76 you used to run xprop from. What we're after is something called
77 WM_CLASS. And within that, only one string. Let me show you:
78
79 $ xprop | grep WM_CLASS
80 WM_CLASS(STRING) = "<unknown>", "Eclipse"
81
82 It's the last string we would use, the "Eclipse" part. That is,
83 if we were doing a definition for this program, an IDE ;-)
84
85 You can see above why I use the last part. Program windows do not
86 always set their "name" (the first string). But they should
87 absolutely set the "class" they belong to, which often coincides
88 with the name.
89
90 So non-technically, this is how expresskeys works now:
91
92 1) Pad button pressed or Touch strips touched.
93 2) Examine which window is the current active one (has focus).
94 3) Get the "class" name of the window.
95 4) Compare that name with an internal list of program names.
96 5) If a match is found, use those keydefinitions.
97 6) If no match is found, use a "default" set of definitions.
98 7) Send the keypress to the specified window.
99
100 In order to achieve this functionality I had to change the
101 "user config area" somewhat. I've done my very best to retain
102 a simple design, and at the same time keep it compact. But
103 success is in the eye of the beholder... Cut out example:
104
105 /*      key_9   */ <-- A visual reminder of which pad button it is.
106         50,     <-- The actual keycode and a COMMA (don't erase it).
107
108 Otherwise all the keys and options from past versions are, almost,
109 the same. End Version Note Rant.
110
111 _Version 0.06 29 March 2005_
112
113 Comment 2 April 2005: This is default only in Gimp. Basic defaults
114 are now Arrow-keys Up/Down/Right/Left. End comment.
115
116 Touch Strip simple implementation. Default, if turned on, sends plus
117 (+) and minus (-) key presses based on finger/stylus up/down motion.
118 This was chosen for Gimp Zoom In/Out functionality. It must be turned
119 on by setting a value in the "user config area", just as for pen mode
120 handling. Default is off, don't handle the touch strips.
121
122 It turns out that with linuxwacom-0.6.7 (beta is out) this program
123 works better than ever! The blender "confusion" I talked about in
124 the previous version note has vanished completely. Also blender
125 zoom, translation and rotation work flawlessly with the pad buttons
126 and pen middle button (was half-working in linuxwacom-0.6.6). So the
127 XTestFakeKeyEvent was no bad choice at all. I'm very pleased :-)
128
129 _Version 0.05 16 March 2005_
130
131 Bugfix. My key scan "case:, if, else, break" flow was somewhat borked.
132 Ugly function but does the right thing now. There are still issues
133 with (I believe) the timing of the XTestFakeKeyEvent of the XTest
134 extension. Using the "u" and "Shift-u" for undo and redo in blender
135 works, but sometimes blender gets confused. Waiting some seconds and
136 doing a "slow-push-release" of the key can fix the issue. Ah well,
137 this simulates keypresses, it's not the real thing... I'll look into
138 using another extension for the simulation.
139
140 _Version 0.04 15 March 2005_
141
142 Bugfix to handle certain key combinations better. Not perfect though.
143 Will debug further.
144
145 _Version 0.03 15 March 2005_:
146
147 Handle a pen from the pad keys (toggle between absolute and relative mode).
148 See the new "user config area" for details. Observe: Whatever pen mode
149 you are in when exiting or killing this program, that's the pen mode
150 you have... So if wrong, fire up the program again and toggle until it's
151 the right mode. Default is off, don't handle a pen.
152
153 Clearly marked and cleaned up a "user config area" at the very beginning
154 of the code.
155
156 _Version 0.02 14 March 2005_:
157
158 Comment 2 April 2005: These instructions are dated. #define
159 for the keycodes are not used anymore. End comment.
160
161 Added the option to specify an extra key for each pad key.
162 "#define KEY_xx_PLUS yy". By setting yy of KEY_11_PLUS to 57 you'd get
163 the famous Ctrl-n ;-). I needed this for undo and redo in blender.
164
165 _Version 0.01 14 March 2005_:
166
167 Original release
168
169 Have fun,
170 Mats
171