Ayatana Indicator Messages Applet https://openid.arctica-project.org/ayatana-indicator-messages/atom?h=main 2012-11-01T16:53:29+00:00 2012-11-01T16:53:29+00:00 Lars Uebernickel lars.uebernickel@canonical.com 2012-11-01T16:53:29+00:00 urn:sha1:97d0cafcae1f64107f786796ead442c0c5401f15 2012-10-09T20:12:15+00:00 Ken VanDine ken.vandine@canonical.com 2012-10-09T20:12:15+00:00 urn:sha1:2ab588d17de27d836a815eff1b310e323097b3db 2012-10-01T15:26:44+00:00 Lars Uebernickel lars.uebernickel@canonical.com 2012-10-01T15:26:44+00:00 urn:sha1:7a1769409539c7d672af51106d0fa186b32bd0ea Instead, silently don't export menus and actions. The single warning about the desktop id being invalid should be enough. 2012-09-18T19:54:37+00:00 Lars Uebernickel lars.uebernickel@canonical.com 2012-09-18T19:54:37+00:00 urn:sha1:24ee0b6602960f35712adbf668099e06b8ebfb25 Up until now, the global chat status was set every time an application called _set_status. Thus, global status really meant "status of the app that last changed the status". Now, the service remembers the chat status for each application and sets the global status as a combination of all of application statuses. If applications have different statuses, the menu items are shown in an inconsistent state. This is implemented in IdoMenuItem by making it accept state as an array of strings in addition to a single string. It is drawn inconsistent if the state contains the menu item's target value in addition to other values. When the global status is changed through the messaging menu, the service doesn't update the action immediately anymore. Instead, it notifies all applications about the change via the "status-changed" signal. Applications must call _set_state to acknowledge that they have indeed changed their state. This is consistent with libmessaging-menu's documentation and design. Also, the SetStatus D-Bus call was missing a "desktop-id" parameter to tell the menu which application changed status. Changing this doesn't break existing apps, as the D-Bus interface is considered private to indicator-messages. 2012-09-18T14:17:57+00:00 Lars Uebernickel lars.uebernickel@canonical.com 2012-09-18T14:17:57+00:00 urn:sha1:da9fde78ca62bd0b05dfbee3e024fd776c29c373 The application's status only changes when it calls _set_status, so it's wrong to set the internal status when the global status changes. This shouldn't be a problem in practice, as app->status is not accessible from the API. 2012-09-18T14:10:15+00:00 Lars Uebernickel lars.uebernickel@canonical.com 2012-09-18T14:10:15+00:00 urn:sha1:624b6e5dd7bd32fc3f57b8c423c52f0d6738d0a7 Only notify the service about status if the application has actually called messaging_menu_app_set_status. This saves a d-bus call per non-chat application and - more importantly - doesn't make the messaging menu go into "unknown status" mode when one application is reporting 'online' status. 2012-09-04T18:49:44+00:00 Lars Uebernickel lars.uebernickel@canonical.com 2012-09-04T18:49:44+00:00 urn:sha1:bd13abddd0740eb9cb0859c4a12cdd77d4819d21 2012-09-02T10:30:12+00:00 Lars Uebernickel lars.uebernickel@canonical.com 2012-09-02T10:30:12+00:00 urn:sha1:78ebf86005bf747ad7f1060e7991d4abeb5ed83f The most common case when inserting a timed source is to insert a source with the current time. Emphasize this in the documentation by linking to the convenience methods from the _with_time variants. 2012-09-02T10:16:14+00:00 Lars Uebernickel lars.uebernickel@canonical.com 2012-09-02T10:16:14+00:00 urn:sha1:3856b84e523ec134d1429cf0cef0546f27754200 2012-09-02T10:12:59+00:00 Lars Uebernickel lars.uebernickel@canonical.com 2012-09-02T10:12:59+00:00 urn:sha1:deff47a562860c1ab698d3861d387208e55bba06