Hi'all, In my quest for keyboard navigation (which works quite well by now btw) I have come upon Dillo's current inability to define custom keyboard bindings (except for menu bindings). GTK+ offers a mechanism to implement user-configurable keyboard mappings (Bindings) which could be used to add this feature to Dillo. I have made a sample implementation using bindings for GtkDwScrolledFrame, which shows the mechanism to work as it should. The resulting object code is slightly smaller than in the current CVS version, but the source is larger (mainly because of the huge list of 'gtk_binding_entry_add_signal9...0 calls for every key combination). To use the mechanism, widgets need to have signals defined for all user actions. In GtkDwScrolledFrame's case this meant adding "viewport_move" (which replaces the unused user_hchanged and user_vchanged signals), "cursor_move", "cursor_hide" and "cursor_activate" (the latter three for keyboard navigation; it is debatable whether these signals belong in GtkDwScrolledFrame or should move to GtkDwViewport). Keybindings are assigned through GTK+ rc-files or through the dillorc. As an example, this configuration (in gtkrc) uses the numerical keypad for link navigation: binding "keypad-keys" { bind "KP_Add" { "cursor_move" (0) } bind "KP_Subtract" { "cursor_move" (1) } bind "KP_8" { "cursor_move" (2) } bind "KP_2" { "cursor_move" (3) } bind "KP_4" { "cursor_move" (4) } bind "KP_6" { "cursor_move" (5) } bind "KP_Enter" { "cursor_activate" () } } class "GtkDwScrolledFrame" binding "keypad-keys" This one (in dillorc, note the enclosing double quotes and the preference name key_bindings) makes Dillo behave like the vi editor when it comes to link navigation: key_bindings = "binding 'vi-keys' { bind 'k' { 'cursor_move' (2) } bind 'j' { 'cursor_move' (3) } bind 'h' { 'cursor_move' (4) } bind 'l' { 'cursor_move' (5) } } class 'GtkDwScrolledFrame' binding 'vi-keys'" (numerical values after "cursor_move" are actually GTK enumeration values, but the current implementation does not support this. It would of course look much better to be able to write "cursor_move" (GTK_DIR_DOWN) instead of "cursor_move" (3)...) Now I could just add this functionality to the keyboard_navigation patch, or put it in a separate patch. However, since there seems to be some animosity against adding yet even more configuration options, I'd like to know if there is any interest in this feature. If not, I'll just keep things as they are and hardcode some sane defaults (ie. something I like...). In that case, those who want to change keyboard bindings can do it the way they have always done by hacking the source. Any suggestions? Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]