summaryrefslogtreecommitdiffstats
path: root/chrome/renderer/render_widget.h
diff options
context:
space:
mode:
authorsuzhe@chromium.org <suzhe@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-09-10 07:22:48 +0000
committersuzhe@chromium.org <suzhe@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-09-10 07:22:48 +0000
commit4467058769b543946faf628c3b20a0803ca3f061 (patch)
treef4011c5e25465f291de65e72f688a46ad2b6677d /chrome/renderer/render_widget.h
parent85f07ece0d4e006389f238c804e77b0496c02c30 (diff)
downloadchromium_src-4467058769b543946faf628c3b20a0803ca3f061.zip
chromium_src-4467058769b543946faf628c3b20a0803ca3f061.tar.gz
chromium_src-4467058769b543946faf628c3b20a0803ca3f061.tar.bz2
Supports Gtk keyboard themes.
This CL fixes issue 11480: Support GTK keyboard themes (emacs keybindings). A new class GtkKeyBindingsHandler has been added, which matches a key event against key bindings defined in current Gtk keyboard theme. A new render message ViewMsg_SetEditCommandsForNextKeyEvent has been added for sending edit commands associated to a key event to renderer. This message shall be sent just before sending the key event. RenderView will handle this event and cache the edit commands until the key event is processed. When processing the key event, EditClientImpl::handleKeyboardEvent() will eventually be called to handle the key event, if it's not handled by DOM and the focus is inside an input box. Then a newly added method WebViewDelegate::ExecuteEditCommandsForCurrentKeyEvent(), which is implemented in RenderView, will be called by EditClientImpl::handleKeyboardEvent() to execute edit commands previously sent from browser by ViewMsg_SetEditCommandsForNextKeyEvent message. If WebViewDelegate::ExecuteEditCommandsForCurrentKeyEvent() returns false, which means the key event doesn't have edit command associated, EditClientImpl will handle the key event with built-in logic, which may trigger a built-in key binding. With this approach, system defined key bindings always have higher priority than built-in key bindings defined in editor_client_impl.cc. Known issue: If a key event matches not only a system defined key binding but also an accesskey of a DOM element, then both corresponding edit commands and accesskey action will be executed. Because accesskey is handled in WebViewImpl::CharEvent(), while edit commands are bound to RawKeyDown or KeyUp events. BUG=11480 "Support GTK keyboard themes (emacs keybindings)" TEST=Switch to Emacs keyboard theme by changing the value of gconf key "/desktop/gnome/interface/gtk_key_theme" to "Emacs", then starts chrome and opens a webpage with a text input box. Input something into the text box, then press any of the Emacs key bindings defined in /usr/share/themes/Emacs/gtk-2.0-key/gtkrc, to see if it works as expected. For example, ctrl-p should move the cursor up one line, and ctrl-k should delete to the end of paragraph. Review URL: http://codereview.chromium.org/165293 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25852 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/renderer/render_widget.h')
-rw-r--r--chrome/renderer/render_widget.h4
1 files changed, 4 insertions, 0 deletions
diff --git a/chrome/renderer/render_widget.h b/chrome/renderer/render_widget.h
index 38dfad8..100aee0 100644
--- a/chrome/renderer/render_widget.h
+++ b/chrome/renderer/render_widget.h
@@ -196,6 +196,10 @@ class RenderWidget : public IPC::Channel::Listener,
// GetWindowRect() we'll use this pending window rect as the size.
void SetPendingWindowRect(const WebKit::WebRect& r);
+ // Called by OnHandleInputEvent() to notify subclasses that a key event was
+ // just handled.
+ virtual void DidHandleKeyEvent() {}
+
// Routing ID that allows us to communicate to the parent browser process
// RenderWidgetHost. When MSG_ROUTING_NONE, no messages may be sent.
int32 routing_id_;