At present the system menu, which you see when you right-click anywhere on the titlebar, left-click the menu button, or right-click an entry on the pager, is hard-coded separately into Metacity and libwnck, and required to be the same in both places.
I’ve been considering the idea of making it a property on the root window called, say, _METACITY_SYSTEM_MENU. Let’s think about how this could look. It would need multiple lines, and multiple fields for each line; so let’s say the lines are delimited by newlines and the fields by tabs, for easier processing. The first field in a line would dictate the function of the line. If it began with a star it would be something special, and we only need to define two of these, “*workspacemove” for “move up, down, left, right a workspace” and “*workspacemenu” for the submenu of workspaces.
Let’s say, though, that if it began with a colon it would represent an EWMH message. A naive approach would be to send these messages when they were chosen; a more efficient approach would be to fake one up and pretend it had been received, to avoid the round trip to the X server. NARGERY: Let’s say that it consists of a number of subfields separated by colons; the first is the atom for the message_type; the second is “W” if the window field is to be filled in with the ID of the current window, and empty otherwise; the third and following are the contents of data.l[n], with any decimal integer standing for itself, a blank standing for zero, a dot followed by any characters representing an atom, S standing for a source indication and T for the current server time. Trailing blanks can be omitted. (For these purposes we pretend that toggling _NET_WM_STATE_HIDDEN minimises and un-minimises.)
Alternatively we could simplify matters by using a percentage sign followed by one of the names of the keybinding actions, such as %close. This would be simpler but less portable to other window managers, if this ever became some kind of a standard.
The remainingfields for an action would be the string which represented it in the current locale and possibly a string representing the keybinding, in case we didn’t want to work it out for ourselves.
Given all this, we’d avoid duplicating the menu in both programs, and more importantly we’d make it possible to add entries to the menu, as requested in GNOME bug 345233 and elsewhere. It has been suggested, for example, that if you have a program installed that allows you to share windows across the network, every window should give you the option of doing so in the system menu. That could quite easily be done using “%run_command_n” here.
(Written during a long compile, so apologies if it rambles. Also bear in mind that squibs of the day are supposed to be blue-sky ideas!)
Photo © appaloosa, cc-by-nc-nd.
GNOME bug 130632 raises the idea of being able to put up the GNOME system monitor with a keystroke bound by default to Ctrl+Alt+Delete, as on Windows, so that users can kill applications and so on. The usability people say this is fine as long as the system monitor gains a prominent logout button. This has been raised against the system monitor as GNOME bug 143235. Perhaps, gentle reader, we should add the keystroke anyway and not wait indefinitely for the system monitor maintainers to add the button.
GNOME bug 549389, which has a couple of duplicates, says that if a window is owned by an app which is running as a user other than the user who’s running Metacity, then it should have “(as fred)” on the titlebars, just as it would have “(on chiark)” or whatever if you were running the app remotely. The obvious very useful case here is to have “(as root)” when you’re running a program as root, to remind you to be careful.
I didn’t expect to get useful suggestions from the 
