Created attachment 28769 [details] [review]
Patch #1. Cleans up "Delete This Menu" menuitem.

Patch 1: According to the HIG
(http://developer.gnome.org/projects/gup/hig/1.0/menus.html#menu-item-types),
delete items don't need trailing "..." characters. That saves us a helper.
Besides, I've cleaned up the remove_panel function.

regs,
 Chris

Created attachment 28771 [details] [review]
Patch #2. Move "New Panel" to the top

Patch 2: It feels more consistent with the rest of the desktop to have "New"
entries at the top of menus (cp. File->New). I've separated it out because I
don't think all of you will like it.

regs,
 Chris

Comment on attachment 28771 [details] [review]
Patch #2. Move "New Panel" to the top

Sorry, resent first patch.

Created attachment 28772 [details] [review]
Patch #2, 2nd attempt.

Okay, so patch 1) contains a number of changes

 a) Don't update the sensitivity of the "Delete This Panel" menu item before
    showing it, just set the sensitivity when creating the menu item.

     => This looks broken. We only create the menu item once, so what happens
        if after we create the menu when delete all our panels but this one?
        The menu item should be insensitive, but it won't be.

 b) Removing the code which adds ellipses if delete requires confirmation

     => Fine with this

 c) Passing the toplevel directly to remove_panel() instead using the 
    "menu_panel" data on the menu item

     => I'm fine with this too (we probably did it when we had the panel menu
        as a submenu of object's context menu - and we could move objects
        between panels, so the panel the menu was created for might not have
        been the same panel as when you clicked on the item)

        However, I want us to get rid of it everywhere for the panel context
        menu if we're going to do it. That means removing the g_object_set_data
        in create_panel_context_menu() and making sure it works everywhere
        down the line.

Conclusion: commit the bit for (b), forget about (a) and if you have time work
on (c). If you don't have time to do (c) (it'll take a fair bit of testing) then
just add:

  /* FIXME: the panel which the context menu refers to cannot change, so
   * we don't need this "find the panel from the menu item" stuff for the
   * context menu. Should remove it and fixup everywhere down the line to
   * use the panel specified at creation time.
   */

For patch 2) you should open another bug cc-ing
usability-maint@bugzilla.gnome.org with your suggestion. Note the original
layout was decided in bug #85619. I suspect the suggestion won't fly, though.
"Add to Panel" is used far more than "New Panel" which is why it makes sense on top.

Patch 1 was rewritten and is in. Patch 2 is WONTFIX.