On Mon, 2010-04-05 at 11:16 -0400, Colin Walters wrote: > The most important thing is to implement the application menu, > offering at least global options like Quit, New Window, About. And we > want to experiment with moving e.g. Copy&Paste in there, which could > get us to the point where basic applications wouldn't need a > per-window menu. For the messaging menu in Lucid we did a little bit of work similar to this, just the menu, not solving any of the other problems you've listed. The design goal was to allow applications a way to provide commonly used messaging functions directly in the menu both when running and not (which many not entirely overlap with your use case). Though, they don't have to be the same items, it would seem that for most applications you'd want the running set to be larger than the static set. The way that the static items work is by basically the Nautilus actions style of adding groups, but it's much much simpler. We only have Name, Exec, and ShowIn. Dynamic items are done by passing a dbumenu object path. This is the same code used by the application indicators. It doesn't provide for actions per se, it's more just standard menu properties though there's no reason they couldn't be Quit and New Window as well. The menu items passed by the application are inserted into the messaging menu. I've attached a screenshot, which is not too exciting, but probably provides some reference for what I'm saying :) In the screenshot "Compose New Message" and "Contacts" are both dbusmenu menuitems exported by the evolution-indicator plug-in. --Ted
Attachment:
Screenshot.png
Description: PNG image
Attachment:
signature.asc
Description: This is a digitally signed message part
