Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Actions not working #4

Closed
panicbit opened this issue Aug 2, 2015 · 15 comments
Closed

Actions not working #4

panicbit opened this issue Aug 2, 2015 · 15 comments

Comments

@panicbit
Copy link
Contributor

panicbit commented Aug 2, 2015

Waiting for actions using show_and_wait_for_action results in blocking forever (the handler never gets called).

@hoodie
Copy link
Owner

hoodie commented Aug 2, 2015

Hi, thanks for the feedback. Would you care to elaborate?
What desktop are you using? (KDE, Gnome, Ubuntu, Xfce, etc)
Are you using v1.0.1 of the crate?
Have you tried the examples:
cargo run --example signal_listener
or
cargo run --example wait_for_closing do these not work either?

Thanks

@panicbit
Copy link
Contributor Author

panicbit commented Aug 2, 2015

Distro: Arch Linux
Desktop: None/i3wm
Notification daemon: Tried notification-daemon (3.16.1) and mate-notification-daemon (1.10.1), both advertise "actions" capability
Crate: Tried 1.0.1 and git HEAD (41dfe5f)

Neither of the examples works as intended.

I'm no dbus expert but I don't see any messages using dbus-monitor when the notification closes or is being clicked.

@hoodie
Copy link
Owner

hoodie commented Aug 2, 2015

Ok, this is nice to know, I was only able to test it against the 4 desktops I listed above and there it worked.
On my end dbus-monitor shows that I works correctly, at least under kde.
But it appears as though all these servers implement the standard a bit differently.
Unfortunately hardly any of the libs that wrap libnotify support actions at all, and I currently can't get a plain/c example to work. I will test it on mate tonight, as for i3wm I can't make any promises.
Could you perhaps try to build some example at proves that i3wm really supports actions?

@panicbit
Copy link
Contributor Author

panicbit commented Aug 2, 2015

Sure, I was going to find some app that uses actions to see if it actions
actually work with my notification daemon. Though, the ability to use
actions SHOULD be independent of the desktop environment.
Currently I'm trying to set up a Ubuntu VM for testing (but it keeps
freezing -.-). I'll also try to find a C example that should work :).
Will report back in a few hours.

Hendrik Sollich notifications@github.com schrieb am So., 2. Aug. 2015
14:50:

Ok, this is nice to know, I was only able to test it against the 4
desktops I listed above and there it worked.
On my end dbus-monitor shows that I works correctly, at least under kde.
But it appears as though all these servers implement the standard a bit
differently.
Unfortunately hardly any of the libs that wrap libnotify support actions
at all, and I currently can't get a plain/c example to work. I will test it
on mate tonight, as for i3wm I can't make any promises.
Could you perhaps try to build some example at proves that i3wm really
supports actions?


Reply to this email directly or view it on GitHub
#4 (comment).

@hoodie
Copy link
Owner

hoodie commented Aug 2, 2015

So, I looked a bit (very briefly) into (one of the) specification(s) of desktop notifications. This is the one the kde people refer to. It states that ActionInvoked is to be emitted by the server, which is what I am listening to in my implementation.

However, looking into d-feet, it appears as though mate-notification-daemon does not emit that signal.
If you are interested in investigating this further we might talk to those guys about it 😃

@panicbit
Copy link
Contributor Author

panicbit commented Aug 2, 2015

I feel like I should take dive into the (mate-)?notification-daemon source to see what's actually going on or what's expected from an "action client"

@panicbit
Copy link
Contributor Author

panicbit commented Aug 2, 2015

WTF @ Ubuntu 15.04:
thread '<main>' panicked at 'Unabled to send message Notify.' , /home/rustbuild/src/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/option.rs:330
I'm not even able to test things :P, thx Ubuntu

@hoodie
Copy link
Owner

hoodie commented Aug 2, 2015

I feel like I should take dive into the (mate-)?notification-daemon source to see what's actually going on or what's expected from an "action client"

Sorry, what do you mean?

@panicbit
Copy link
Contributor Author

panicbit commented Aug 2, 2015

I mean that I should take a look at the source of the gnome
notification-daemon to figure out what it expects you to do when you want
to receive feedback on actions.

@hoodie
Copy link
Owner

hoodie commented Aug 2, 2015

Well, I only tested gnome3, but the signals ActionInvoked and NotificationClosed were emitted there too. Thanks for looking into this, I actually though testing on like 4 different desktop environments was enough, and expected mate to work, because xfce worked fine too.

@panicbit
Copy link
Contributor Author

panicbit commented Aug 3, 2015

Here's a log from dbus-monitor while running the wait_for_closing example:

signal sender=org.freedesktop.DBus -> dest=:1.56 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.56"
method call sender=:1.56 -> dest=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "eavesdrop=true"

[run wait_for_closing example]

signal sender=org.freedesktop.DBus -> dest=(null destination) serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.57"
   string ""
   string ":1.57"
method call sender=:1.57 -> dest=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello
method call sender=:1.57 -> dest=org.freedesktop.Notifications serial=2 path=/org/freedesktop/Notifications; interface=org.freedesktop.Notifications; member=Notify
   string "wait_for_closing"
   uint32 0
   string ""
   string "Don't Mind me"
   string "I'll be gone soon enough.
Sorry for the inconvenience."
   array [
   ]
   array [
   ]
   int32 -1
method return sender=:1.7 -> dest=:1.57 reply_serial=2
   uint32 5
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=5 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.57"
   string ":1.57"
   string ""
signal sender=org.freedesktop.DBus -> dest=(null destination) serial=6 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.58"
   string ""
   string ":1.58"
method call sender=:1.58 -> dest=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello
method call sender=:1.58 -> dest=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "interface='org.freedesktop.Notifications',member='ActionInvoked'"
method call sender=:1.58 -> dest=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "interface='org.freedesktop.Notifications',member='NotificationClosed'"

[notification closes after a while]

Also, looking at the source of notification-daemon everything should be emitted as expected. See on_notification_action_invoked and on_notification_close.
Maybe there really is some oddity going on with i3wm.
I'll try to find another app now that uses actions to verify if they actually work on i3wm 😐.

EDIT:
Actions work fine using this python snippet:

import gtk
import pynotify

class Demo:
    def __init__(self):
        pynotify.init("demo")
        n = pynotify.Notification("Summary", "details")
        n.add_action("foo", "Foo!", self.fooAction)
        n.show()
        gtk.main()

    def fooAction(self,notifyObj, action):
        print("Foo action!")
        notifyObj.close()
        gtk.main_quit()

if __name__ == "__main__":
    obj = Demo()

EDIT 2:
I've noticed that rust-notify sends AddMatch messages after sending the notification but this python script sends the AddMatch messages before sending the notification.
Might this make a difference?

@hoodie
Copy link
Owner

hoodie commented Aug 3, 2015

  1. Ok, so you are saying mate and i3wm both support actions fine, and this python script proves it?
  2. I also use archlinux, but I can't get pynotify installed through pip, how did you do it?
  3. I would like to fix this, but I am busy studying for an exam I have in 3 weeks, though I would be happy to review a PR if you want to fix this integration sooner than this 😃

@panicbit
Copy link
Contributor Author

panicbit commented Aug 3, 2015

  1. Yup
  2. I uses the python2-notify package
  3. Don't worry, I'm already fiddling with the source 😄

@hoodie
Copy link
Owner

hoodie commented Aug 3, 2015

👍

@panicbit
Copy link
Contributor Author

panicbit commented Aug 3, 2015

I actually got it to work! Pull request will follow soon ;).
It appears to me that the original dbus connection, which opened the notification, needs to stay alive.

@hoodie hoodie closed this as completed Aug 3, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants