From: William Lachance (wlach@interlog.com)
Date: Fri Aug 23 2002 - 01:18:18 EDT
Refresher:
http://bugzilla.abisource.com/show_bug.cgi?id=3773
http://bugzilla.abisource.com/show_bug.cgi?id=1194
--O.k., I tried to get to the bottom of the keyboard mess today. I think I have finally figured out (mostly) what is going on. This might not be news for some of the old-timers, but others might find it interesting.
First of all, it doesn't look like it's really a problem that we handle key-presses at the top-level w.r.t the GTK2 port. It might be desirable, for code-aesthetic reasons (and in case we wanted to have editable combos in the toolbar), to handle key-presses through the document widget, but it's not really that big an issue, and not so hard to touch up (only really involves switching some signals around).
Now here's the process:
On startup, we create bindings for all keys (ASCII keys, international extensions, shortcuts, etc.) by looking up hard-coded arrays. The user is able to set up different bindings, that's how we get things like the 'emacs' keymode. We store the bindings in a special table called an EV_EditBindingMap, which stores a set of keys, modifiers, and actions (functions by string name) for the application to respond to.
In both the Win32 and GTK2 ports, we then deal with these events through the app itself, by binding the top-level window to detect key-presses. On GTK2, we seem to be doing things in a fairly standard way for this sort of app-- we simply add-up which GDK keys are pressed down (say, 'alt-ctrl-a') and hand it off to the appropriate function. The only thing that's a little weird is that we handle shortcuts ourselves, instead of using accelerators.
On Win32, on the other hand, we seem to be using a lower-level function than is normal to get the correct key-combination (see ev_Win32Keyboard.cpp in af/ev/win). This is, apparently, so we can get shift+modifiers on certain keys (e.g.: 2).
--
Observations:
This approach involves a lot of book-keeping. The code is difficult to understand (not helped by the fact that the code uses variable names like 'pEEM', but that's another story..) and maintain.
Now, with respect to the Win32 port, taking on the responsibility of handling key-presses at such a low-level means we can't take advantage of platform niceties (that would, probably, make things like symbol insert on (Alt-XXX) and support for different keymaps MUCH easier, if not automatic). What we gain isn't much (is it really that valuable to be able to generate a 'shift-ctrl-2' for event handling?) --
Here is the course of action I recommend:
1. Define the shortcut-keys (e.g.: ctrl-s) in some other way (e.g.: in another class, or ideally, put them in a preference file), and bind them to the native toolkit on initialization. POTENTIAL PROBLEM: Can every platform do this? GTK2 definitely has facilities for it, Win32 probably does. If worse came to worse, a platform maintainer could probably roll his own solution.
2. Create special bindings for the keys which modify the document view, but aren't shortcuts per se (e.g.: page-down, insert, etc.). We will probably want to do something similar to what we're doing right now with these (e.g.: a binding to a function, which we ultimately respond to in the xp keyboard event handler), although we can probably ditch a lot of the complexity involved (e.g.: these keys probably don't need modifiers). Again, it would also be desirable to put these key-bindings in a preference file, so people can modify them there.
3. Finally, take the keys representative of data (e.g.: 'a', 'b', etc.) at face value in platform-specific code, and insert them into the document-window. We can probably do this without defining specific bindings. This would (probably) make it easier to do things like add alt-insert-symbol on Win32.
I think, overall, these changes would make the code far simpler and easier to maintain. We would lose the emacs and vi keybindings (for instance), and it might be impossible to get them back, if they depend on the current windows keybinding arrangement. I don't really see this as much of a loss, but perhaps others might think differently..
I'm willing to do the work necessary to get this up-and-running on the Unix (GTK2) port. Someone else will have to take on the (substantial) job of reworking the Win32 keyboard code to both fit into this new approach, and make it use higher-level win32 functions.
Regardless, I would appreciate feedback from the Win32-Platform experts on my thoughts, as the most serious problems are on that platform.
Regards,
William Lachance wlach@interlog.com
This archive was generated by hypermail 2.1.4 : Fri Aug 23 2002 - 00:24:43 EDT