summaryrefslogtreecommitdiffstats
path: root/chrome/browser/gtk/menu_gtk.h
diff options
context:
space:
mode:
authorestade@chromium.org <estade@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-12-31 02:08:06 +0000
committerestade@chromium.org <estade@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-12-31 02:08:06 +0000
commitf7adea03bde76bbb9824370649363ed198a7b9fe (patch)
tree76e396b23d3ddaa84716198b94a45dc0582f8bcc /chrome/browser/gtk/menu_gtk.h
parentc08c41d094abd9182878a3c4578dfc0a84df1c10 (diff)
downloadchromium_src-f7adea03bde76bbb9824370649363ed198a7b9fe.zip
chromium_src-f7adea03bde76bbb9824370649363ed198a7b9fe.tar.gz
chromium_src-f7adea03bde76bbb9824370649363ed198a7b9fe.tar.bz2
GTK: Remove OwnedWidgetGtk wrapper for the GtkMenu* in MenuGtk.
The "execute the command later" workaround, which was in place to avoid OwnedWidget-DCHECKing when selecting menu items that might cause cascading object-destruction effects, caused problems with the Browser::SetBlockCommandExecution() workaround, the reasoning for which can be found in BrowserWindowGtk and is reproduced here: // This piece of code is based on the fact that calling // gtk_window_activate_key() method against |window_| may only trigger a // browser command execution, by matching either a global accelerator // defined in above |kAcceleratorMap| or the accelerator key of a menu // item defined in chrome/browser/gtk/standard_menus.cc. // // Here we need to retrieve the command id (if any) associated to the // keyboard event. Instead of looking up the command id in above // |kAcceleratorMap| table by ourselves, we block the command execution of // the |browser_| object then send the keyboard event to the |window_| by // calling gtk_window_activate_key() method, as if we are activating an // accelerator key. Then we can retrieve the command id from the // |browser_| object. // // Pros of this approach: // 1. We can handle accelerators defined not only in above // |kAcceleratorMap| table, but also those in standard_menus.cc. // 2. We don't need to care about keyboard layout problem, as // gtk_window_activate_key() method handles it for us. // // Cons: // 1. The logic is a little complicated. // 2. We should be careful not to introduce any accelerators that trigger // customized code instead of browser commands. The easiest and cleanest thing is just to remove the OwnedWidgetGtk. BUG=none TEST=interactive ui tests pass again Review URL: http://codereview.chromium.org/522028 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35404 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/browser/gtk/menu_gtk.h')
-rw-r--r--chrome/browser/gtk/menu_gtk.h5
1 files changed, 2 insertions, 3 deletions
diff --git a/chrome/browser/gtk/menu_gtk.h b/chrome/browser/gtk/menu_gtk.h
index 1b48253..e68759f 100644
--- a/chrome/browser/gtk/menu_gtk.h
+++ b/chrome/browser/gtk/menu_gtk.h
@@ -12,7 +12,6 @@
#include "base/gfx/point.h"
#include "base/task.h"
-#include "chrome/common/owned_widget_gtk.h"
class SkBitmap;
@@ -111,7 +110,7 @@ class MenuGtk {
gboolean* push_in,
gpointer userdata);
- GtkWidget* widget() const { return menu_.get(); }
+ GtkWidget* widget() const { return menu_; }
private:
// A recursive function that transforms a MenuCreateMaterial tree into a set
@@ -164,7 +163,7 @@ class MenuGtk {
// gtk_menu_popup() does not appear to take ownership of popup menus, so
// MenuGtk explicitly manages the lifetime of the menu.
- OwnedWidgetGtk menu_;
+ GtkWidget* menu_;
// True when we should ignore "activate" signals. Used to prevent
// menu items from getting activated when we are setting up the