Re: application class thoughts

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

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.


Attachment: Screenshot.png
Description: PNG image

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]