| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| |
| |
| | |
descriptions Fixes: 1313561
Approved by: Ted Gould
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
| |
The D-Bus protocol is not part of the public API, so it's okay to change it.
|
|
|
|
|
|
| |
In most cases, apps will want to draw the user's attention when they add a
message to the menu.
|
|\ |
|
| |\
| | |
| | |
| | |
| | |
| | | |
https://bugs.launchpad.net/bugs/1154099.
Approved by PS Jenkins bot, Ted Gould.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Prior to this patch, the messaging menu only marked apps as "not running" when
they quit (i.e. disappeared from the bus). This was okay, since most
applications only ever release the ref to their MessagingMenuApp when they
quit, or after calling _unregister explicitely (which removes them from the
menu entirely).
However, this is according to libmessagingmenu's documentation, and at least
indicator-telepathy relies on it.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Detailed action names are of the form action::target or action(target), so they
can't have colons or parens in them. This restriction does not apply to
messaging menu ids.
|
| |/
| |
| |
| | |
_set_draws_attention
|
| |
| |
| |
| |
| |
| | |
The format string passed to g_variant_get calls for four parameters, but only
three were given.
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | | |
Approved by Gustavo Pichorim Boiko, PS Jenkins bot.
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This can happen if noone outside of MessagingMenuApp holds a reference to the
message and somebody calls remove_message() with a pointer they got from
_get_message() (which doesn't return a ref).
messaging_menu_app_remove_message_by_id() really wants a valid 'id' pointer
during its lifetime.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
And add parameters 'action' and 'parameter' (though they are not set yet).
|
| | |
|
| |
| |
| |
| |
| |
| | |
Right now, this is only used to clean up internal data structures in
libmessaging-menu. It's not exposed to the application itself.
|
| | |
|
| |
| |
| |
| |
| | |
This is not exposed in the indicator menu yet.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, the protocol was simply a menu model and an action group of the
currently active sources. The service inserted the menu as a section into the
indicator menu.
This doesn't work anymore, because applications can (soon) expose individual
messages, and the messaging menu doesn't always display all of those at once.
This patch introduces a more specific d-bus API.
That API is still considered private: applications have to use
libmessaging-menu.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Both the service (in src/) and the client library (in libmessaging-menu/) need
access to the dbus interface description file. Until now, it resided in src,
with both Makefiles calling gdbus-codegen on it.
This patch moves the file to common/ and builds a convenience library that
contains only the generated code.
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| | |
Adds MessagingMenuMessage, which allows adding individual messages with titles
and body previews to the messaging menu with messaging_menu_app_append_message.
This only adds the new API, messages are not actually sent to the messaging
menu yet.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
MessagingMenuMessage allows adding individual messages with titles and body
previews to the messaging menu with messaging_menu_app_append_message.
This only adds the new API, messages are not actually sent to the messaging
menu yet.
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
libmessaging-menu: unexport action group and menu model on dispose.
|
| |/ |
|
|/ |
|
| |
|
|
|
|
|
|
| |
Instead, silently don't export menus and actions. The single warning about the
desktop id being invalid should be enough.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
In particular, mamke sure the <c:namespace> and <package> tags are included in
the .gir.
Fixes launchpad bug #1044096, thanks Jim!
|