esiqveland / notify

notify is a go dbus implementation for delivering desktop notifications over dbus

notify

Notify is a go library for interacting with the dbus notification service defined by freedesktop.org: https://developer.gnome.org/notification-spec/

notify can deliver desktop notifications over dbus, ala how libnotify does it.

Please note notify is still in motion and APIs are not locked until a 1.0 is released.

More testers are very welcome =)

Depends on:

• godbus.

Changelog

• v0.11.2: Introduce helpers ExpireTimeoutSetByNotificationServer, ExpireTimeoutNever
• v0.11.1: Fix a race during Close() #11
• v0.11.0: re-release under BSD license
• v0.10.0: stricter types: some breaking changes
• v0.9.0: some breaking changes
• v0.2.1: dbus: gomod: lock to dbus v5
• v0.2.0: Notifier.Close() no longer calls .Close() on the underlying dbus.Conn

Quick intro

See example: main.go.

Clone repo and go to examples folder:

go run main.go

TODO

• Add callback support aka dbus signals.
• Tests. I am very interested in any ideas for writing some (useful) tests for this.

See also

The Gnome notification spec https://developer.gnome.org/notification-spec/.

Contributors

Thanks to user emersion for great ideas on receiving signals.

Thanks to Merovius for fixing race during Close().

License

BSD 3-Clause

notify's Issues

Clarification needed

I see that for every a notification is sent without Notifier we do:

• create Notification
• open DBus connection
• send Notification
• close DBus connection

In that case, if I send several using that protocol, I can close them individually by clicking on them (real-life use case).

Now, if I send several Notification objects with the same connection context, clicking on any of them results on all of them getting closed.

With Signal Listener

Now, in the other scenario is when we have set Action items to the Notification and set up a Notifier with handlers to listen on notification-related events.

• If the Notifier connection is Closed, then signals don't arrive to the handlers.
• Withe the Notifier connection open, one can use Notifier.Send() to send Notification coupled to the listeners as long as the Connection isn't closed.
• If one uses the same open Notifier instance to send several signals, then ALL are bundled together, meaning that if the user closes one (or clicks for Action), then all get closed together which isn't the intended scenario.

So, the only way it would work is if you have one Notifier instance for every Notification send via Notifier.Send(). That's somewhat cumbersome.

Notification.Hints

Hello could you please add an example for notification hints, like urgency sound and so on it would be very helpful.
Thx for good work.

How to use hyperlinks?

Are hyperlinks to be formatted in a special manner in the Notification body?

When I query Server Capabilities (notify-daemon + dunst) it returns a true value for Actions & Hyperlinks in body.

If I put a hyperlink such as https://allmylinks.com/lordofscripts it just appears as plain text in the notification pop up. And clicking on it simply closes the notification. So I have no idea what I am missing there.

Document how to use notification server's default ExpireTimeout

Change 2faf6e5 is good in overall sense (Go-idiomatic to use time.Duration for time intervals).

I used to use this pattern:

notify.Notification{
    ExpireTimeout: -1, // use default for notification daemon
}

Here's a quote from the spec:

If -1, the notification's expiration time is dependent on the notification server's settings, and may vary for the type of notification. If 0, never expire.

It is sent in the DBus protocol as milliseconds, so the duration has to be converted to milliseconds.

Now if I want to request the the notification server to dictate the expiration, I have to do this to get -1 sent over DBus:

notify.Notification{
    ExpireTimeout: -1 * time.Millisecond, // use default for notification daemon
}

Which reads more confusing than the old unit-less -1 😄

But seeing this took some time for me to debug why my system's behaviour changed to weird, perhaps this could be documented somewhere?

Also would it make sense to expose var ExpireTimeoutSetByNotificationServer = -1 * time.Millisecond from the package? Then we could do:

notify.Notification{
    ExpireTimeout: notify.ExpireTimeoutSetByNotificationServer,
}

Multiple notifications get mixed up

Thanks for this useful library. When I open multiple notifications with actions, it seems that when the user triggers an action (by pressing a button) in one of the notifications, the action gets executed as often as there are notifications, and the buttons in the other notifications no longer work.

Code:

https://github.com/probonopd/go-appimage/blob/f1f729f5e55d6f58b7f988dd522699df7f475090/src/appimaged/notification.go#L104

Am I doing it wrong?

Notification subscriber

Hi.
Is it possible to add implementation of notification subscriber to your code. I know you already have eventLoop but 'notificationDelivery' event is missing. I'd like to implement listener of all incoming notifications.

Can't compile

I am trying to use this repository library in an experimental demo.

Despite having done the go gets (for notify & godbus/v5) and have imported them, when I try to compile my demo it complains that notify doesn't have SoundWithName nor Variant, and yet they are there in the source!

Strange thing that also when I issue go doc notify it shows all the types and constants except for SoundWithName() and Variant{}.

Please consider other license options

Hi @esiqveland, I would like to use notify in a MIT-licensed project. Do you allow this?

V1 plan

Might as well make a v1 release after 9 years.

v1 releases usually plays nicer with go modules anyway.

Plan:

V1 TODO

• delete deprecated notify.Variant
• all hint helpers must start with Hint.*
• adhere to: "accept interfaces, return concrete types"
  • delete the big Notifier interface
  • return *Notifier as the concrete type
• make all functions consistently use a *Notification pointer, so we can use fluent apis when creating a notification, something like:

n := newBaseNotification().
    SetUrgency(UrgencyLow).
    AddHint(HintImageData(myImage)).
    AddHint(HintSoundName("new-message))

notifier.Send(n)

This is not possible today, because the Send() method takes a value object

Possibly incorrect usage of `sync.WaitGroup` in the example

Hi, great library.

One thing I've noticed while using it is that sync.WaitGroup in the examples is not really needed, because the library uses it under the hood: https://github.com/esiqveland/notify/blob/master/notification.go#L274

Testing

Don't have many ideas for writing tests for this.

Maybe some ideas here:

• https://github.com/coreos/go-systemd/tree/master/dbus

Default Action

When you set more than one Action in a Notification you can (and should!) mark one as the default action. Currently your package doesn't handle that use case, yet it is very easy to do (just found out!).

See How to set default action

So basically, the action name should be default but the label can be anything.

Color-code Urgency

I was originally using TheCreeper/go-notify but switched to your excellent package because the other only supported sending without signals.

The other package uses DBus Hints to set up the Notification urgency. It is set the same as you use sound hints here.

So, I used the same to specify the urgency using your package. However, I noticed that with his, the pop ups have different background colors based on the "urgency" hint, but when I do it with yours they all have the same color. His code doesn't set colors anywhere so it is done by the DBus server, so I guess that your package (or perhaps it's underlying dbus/V5 is annihilating this hint.

Any ideas?

Possible issue with v0.13 example

When I was working in my wrapper (your package v0.11) I noticed you called wg.Done() within the onAction handler but not in onClose.

In your new update (v0.13.2) you call wg.Done() in both handlers. I think there is an issue there because at least on the notification server I use (Dunst), you can receive first onAction followed by onClose resulting in wg.Done() being called twice for the same notification.

Actions not shown on notification

In my experiment I do the same as your test:

• create a Notification without Action
• send it
• clicked on it to close it

Then I use the same Notification and add the two Action objects to Notification.Actions and send it again to the server.

In both cases the notification pops up and if not clicked (Close) it eventually times out. However, the Action doesn't seem to work:

• The open/cancel actions injected into the Notification object do not appear visually on the notification body.
• When one clicks on any part of the body, the action-enabled notification does nothing else than closing. So the onAction callback never gets invoked.

So:

• Notification body may be pretended with (A) but that can be disabled in the server.
• the actions are apparently not rendered in the body. When user does Middle mouse click the system is supposed to display a context menu but it doesn't.