Launchpad Entry: dx-karmic-messaging-menu
Packages affected: indicator-messages
The MessagingMenu was added to the panel in the Jaunty release cycle. It has gotten a whole heap of reviews and community comments which have resulted in many ideas for its evolution. This spec is to track that evolution in Karmic.
- Messaging menu updated with new applications and the ability to show and activate applications that are not currently running.
Issues in v1
- Used 'Get' to find indicators (auth.log errors)
- Fixed in trunk to use DBus introspection -- slower, but more 'correct'
- API too narrow -- required apps to 'lie' to MI in order to get an effect
- See below
- Code quality, no real test suite.
- Partially fixed in trunk
- E-mail and instant message are treated as the same priority
- Application support limited need:
- Evolution plug-in issues:
- Can't go right to the messages that are interesting
- Perhaps go to unread messages in the inbox if you select the inbox
- No C# bindings for C# applications
- No information on when the item appeared on the menu. For example: I just got a notification, where is it? Results in an increased search time.
- New props:
label -- Text shown in the menu item. Typically this should be the person sending the message or the mailbox. May contain a count.
icon -- The icon shown in the menu item. Typically this should be the user icon of the person sending the message.
time -- The time that is associated with this time. This should be the most recent message or the time the IM was sent. If a time is not provided, the time will be assumed to be the time the indicator was sent.
display_time -- Controls whether or not the time is displayed in the right hand column of the menu.
draw_attention -- This item should signal the user that it has been placed in the menu. Currently this is "show the green dot."
count -- Number of entries of a particular topic. Should be an integer that by default is zero and not shown. Only non-zero counts are shown.
- No more than 7 items should be shown for any application.
- Should it be dynamic? Perhaps there are differing constraints that make sense
- Does this lead to a fuzzy spec?
- Migration would include using the "subtype" to migrate the old properties to the new properties.
- Visibility of applications not running
- Allow applications to put desktop file in somewhere (/etc/indicators/messaging ?)
- Desktop files would provide "On" and "Off" strings (e.g. "Start monitoring Instant Messages" to "Show Buddy List")
- Provides a more central place for messaging
- Clean up the APIs and make it so there are less "magic numbers" -- important for other folks looking at
- Launching Applications:
- Every application thinks they're important, which ones should we include?
- Users should be able to block
- Does this include an unwieldy preference dialog that isn't truly useful for most users?
- How do users control the entries in the menu?
- No other issues, everyone thinks everything is perfect.
- Future work
- How applications should specify they appear in the Messaging Menu
- How this should be integrated with the packaging