Background: Make Asynchronous #84
Conversation
| notification.response (NotifyBackgroundResult.CANCELLED); | ||
| if (reason == CANCELLED) { // Closed via DBus call | ||
| notification.response (CANCELLED); | ||
| } else { // Dismissed, Expired, or something internal to the server |
There was a problem hiding this comment.
A expired signal is also sent when the notification bubble closes. I think it's better to keep waiting then because the notification will stay in the indicator and can still send a response when something like elementary/wingpanel-indicator-notifications#258 gets merged.
There was a problem hiding this comment.
This's a notification server bug, currently the server and indicator works at the back of each other, making the integration between both a mess. I'm working in a "rewrite/refactor" of the server right now, so that we can support the indicator properly.
we can wait till the server is fixed, but i don't see why, because the expiration would make the action activation useless in the server side. and we would need to fix that before something like elementary/wingpanel-indicator-notifications#258 is merged.
There was a problem hiding this comment.
Only out of curiosity: Why would the expiration make the action activation useless even if we ignore the expiration signal?
There was a problem hiding this comment.
If the server emits a NotificationClosed signal it's mean that the notification doesn't exists anymore. so there will be no other signal emission for that notification id from the server.
| } | ||
|
|
||
| var path = Path.build_filename (Environment.get_user_config_dir (), "autostart", _app_id + ".desktop"); | ||
|
|
||
| var file = File.new_build_filename (Environment.get_user_config_dir (), "autostart", _app_id + ".desktop"); |
There was a problem hiding this comment.
Only out of curiosity: What's the advantage here?
There was a problem hiding this comment.
GLib recommends that we should use the asynchronous versions of the methods in asynchronous code. In this case, it's reduce the chances that we slow or block others methods and others portals.
* move dbus interfaces out of the classes bodies, use constants for path and name. * use enumeration values where applicable and skip the namespace when possible. * simplify the response callback in the notify_background(). * make the notification_closed() callback return ALLOW_ONCE in more types of reasons. * remove temporary variables where applicable. Signed-off-by: Gustavo Marques <[email protected]>
make all of the dbus calls and methods asynchronous so that we don't end up blocking others interfaces, methods and initialization. the notification proxy is now also started when we first call send_notification() so we don't end starting it early than necessary or blocking the initialization for too much time. Signed-off-by: Gustavo Marques <[email protected]>
Marukesu
force-pushed
the
maru/background-async
branch
from
5347f1a
to
46848f6
Compare
Make all of the DBus calls and methods asynchronous so that we don't end up blocking others interfaces, methods and initialization. The notifications server proxy is now started when we first call
send_notification()so we don't end starting it early than necessary.