GNOME Bugzilla – Bug 594557
Hack "new window" option into app well menu
Last modified: 2009-09-17 20:39:57 UTC
I think it would make people happy if we always had "New Window" in the app well menu, even if for right now we just hack it to relaunch the desktop file. That is, the gain for having it there for Firefox is bigger than the apparent bug for the single-instance app that doesn't open a new window when relaunched. (jrb suggested that maybe we just hack it in *just* for Firefox ... another option.)
(gross hack alert) we could set GTK_MODULES to point to a module that watched for GtkMenuBar creation, and set a property on the process leader window indicating whether or not there was an item with the shortcut "Ctrl+N" near the top of the first menu. ShellAppMonitor could track that, and then the app well could omit the New Window item for apps that it knew didn't have a New Window menu item (but, for now at least, leave it there for the apps that it wasn't sure about)
(In reply to comment #1) > (gross hack alert) we could set GTK_MODULES to point to a module that watched > for GtkMenuBar creation, and set a property on the process leader window > indicating whether or not there was an item with the shortcut "Ctrl+N" near the > top of the first menu. ShellAppMonitor could track that, and then the app well > could omit the New Window item for apps that it knew didn't have a New Window > menu item (but, for now at least, leave it there for the apps that it wasn't > sure about) Which wouldn't work for Firefox, which is the main one that people want this for...
Created attachment 143387 [details] [review] [AppWell] Add "New Window" menu item Refactor the current menu code to support both window selection and "normal" menu items. Add a "New Window" item which does what you'd expect.
Created attachment 143390 [details] [review] Add "New Window" menu item Refactor the current menu code to support both window selection and "normal" menu items. Add a "New Window" item which does what you'd expect.
Comment on attachment 143390 [details] [review] Add "New Window" menu item >+ this._newWindowMenuItem = this._appendMenuItem(null, _("New Window")); if the window is showing icons, the "New Window" item will end up aligned to the left edge, rather than being aligned with the titles of the other windows, which is probably wrong? >- _onWindowSelected: function (actor, child) { >- this._setHighlightWindow(child._window); >+ _onItemSelected: function (actor, child) { >+ if (child._window) >+ this._setHighlightWindow(child._window); >+ else >+ child.background_color = WELL_MENU_SELECTED_COLOR; The division of labor in window-selection-handling seems like it could be cleaned up; here you know the menu item in question ("child"), but you don't pass it to setHighlightWindow, which then walks through the list of children trying to find it again. And then it sets child.background_color to the same thing as you would be setting it to if you didn't call setHighlightWindow here. A different way to do it would be to have onItemSelected do the background-color-setting and signal emission, and have setHighlightWindow just call onItemSelected/Unselected after finding the correct menu item child. Or something like that.
(In reply to comment #5) > (From update of attachment 143390 [details] [review]) > >+ this._newWindowMenuItem = this._appendMenuItem(null, _("New Window")); > > if the window is showing icons, the "New Window" item will end up aligned to > the left edge, rather than being aligned with the titles of the other windows, > which is probably wrong? Good point, hm; I guess what we really want here is a more concretely styled/fleshed out menu class (one which would also say allow following the gconf key for icons in menus), then I can have New Window use gtk-add. Probably a js/ui/popupMenu.js. But we shouldn't block the immeidate merge on this I think. > A different way to do it would be to have onItemSelected do the > background-color-setting and signal emission, and have setHighlightWindow just > call onItemSelected/Unselected after finding the correct menu item child. Or > something like that. Following patch should do that.
Created attachment 143396 [details] [review] Add "New Window" menu item Refactor the current menu code to support both window selection and "normal" menu items. Add a "New Window" item which does what you'd expect. Clean up the way we handle highlighting the window items to be more direct; rather than looping over all items in most cases, just directly manipulate one item
Comment on attachment 143396 [details] [review] Add "New Window" menu item this loses the lightboxing when you move the pointer over a window (as opposed to over its menu item). was that intentional? otherwise good
Created attachment 143403 [details] [review] Add "New Window" menu item Refactor the current menu code to support both window selection and "normal" menu items. Add a "New Window" item which does what you'd expect. Clean up the way we handle highlighting the window items to be more direct; rather than looping over all items in most cases, just directly manipulate one item
Attachment 143403 [details] pushed as 2c0661d - Add "New Window" menu item