diff options
author | suzhe@chromium.org <suzhe@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-09-10 07:22:48 +0000 |
---|---|---|
committer | suzhe@chromium.org <suzhe@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-09-10 07:22:48 +0000 |
commit | 4467058769b543946faf628c3b20a0803ca3f061 (patch) | |
tree | f4011c5e25465f291de65e72f688a46ad2b6677d /chrome/renderer/render_widget.h | |
parent | 85f07ece0d4e006389f238c804e77b0496c02c30 (diff) | |
download | chromium_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.h | 4 |
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_; |