I dedicated the last weekend to write yet another X11 utility: xnotify.
It is a notification launcher that reads notification from the stdin and displays it on your screen.
You can create a fifo in order to echo stuff into it.

For example:


Would create a notification with “Hello World” as its content.

Here's a demo gif that illustrates its usage.


To launch xnotify, add the following to your ~/.xinitrc:


You can use it together with tiramisu, an application that outputs notifications to the stdout.

I still have to improve the text and image placement on the notification window, so any idea is welcome.

So, what do you think?

Maybe add an option to automatically shrink the notification like in dunst? Other than that I think it looks great and thanks for bringing tiramisu to my attention.

(21-09-2020, 11:47 AM)sokx Wrote: Maybe add an option to automatically shrink the notification like in dunst?

Interesting. Does it shrinks the notification width, height, or both?
I do not use dunst so I have no idea.
In dunst the notification height is fixed or does it depend on its content (like, when there is a icon, the notification gets bigger)?

Funny, I just saw your post on /r/suckless. Looks like a great little tool!

(21-09-2020, 12:05 PM)phillbush Wrote: Interesting. Does it shrinks the notification width, height, or both?
I do not use dunst so I have no idea.
In dunst the notification height is fixed or does it depend on its content (like, when there is a icon, the notification gets bigger)?

Sorry, don't know why I assumed that everyone knows how dunst works. If you enable shrinking in dunst, each notification that is smaller than the geometry specified in the config file will get their size based on the font size, padding, line height and image size. Wish I could just take a screenshot for you, but I'm not on *nix atm and couldn't find anything on google.

(21-09-2020, 01:27 PM)sokx Wrote: Sorry, don't know why I assumed that everyone knows how dunst works. If you enable shrinking in dunst, each notification that is smaller than the geometry specified in the config file will get their size based on the font size, padding, line height and image size. Wish I could just take a screenshot for you, but I'm not on *nix atm and couldn't find anything on google.

No problem, I read dunst's manpage and I now understand how it works (and I stole some of its features too).

Hi phillbush,
I find xnotify very appealing, spesifically something without a dbus dependency is on my high list.
Currently using dunst, and I use it not only for notifications but also as a dock for minimized windows.
I have some questions for possible features request;
one is regarding updating a notification (like dunstify --printid and --replace option) for volume/brightness stuff
and the other is exec a action on left mouse click rather than close?
Hopefully I will have the opportunity to do some testing/experimenting upcomming weekend.
Anyways thanks!

(22-10-2020, 12:19 AM)biopsin Wrote: spesifically something without a dbus dependency is on my high list

Can you explain why? This was asked on Reddit but didn't get a response.

(26-10-2020, 10:56 PM)Ramiferous Wrote: Can you explain why? This was asked on Reddit but didn't get a response.

D-bus is often missused in a lot of applications as a transport protocol instead of being used for RPC. It's not meant to be fast nor efficient. But then you see applications that spam battery status every second, which this isn't meant to be something d-bus do.

D-bus is a middleware that provides interfaces that software could possibly provide, on a contractual basis. When it comes to notifications, it standardize the interface and say "whoever attaches as the notification receiver will respect this interface", found here.
It also has good introspection capabilities to explore what services attached to the bus provide. Like for example, on IRC we were discussing how Firefox implemented the MediaPlayer2.Player interface, allowing you to remotely control the videos playing within Firefox through d-bus.
That's my 2 cents after writing this summary.

(22-10-2020, 12:19 AM)biopsin Wrote: I have some questions for possible features request;
one is regarding updating a notification (like dunstify --printid and --replace option) for volume/brightness stuff
and the other is exec a action on left mouse click rather than close?
Hopefully I will have the opportunity to do some testing/experimenting upcomming weekend.

Sorry for not responding earlier, I'm having a busy week.

Yeah, these additions are in my TODO list.
I will add a group or id feature where you can tag a notification for being of a given group/id and it will replace all other notifications of the same group/id.
I'm also considering to add some kind of click behavior, maybe output the notification to stdout when the user click with a given mouse button on the notification, and then the user should pipe xnotify stdout to a script.

(26-10-2020, 10:56 PM)Ramiferous Wrote: Can you explain why? This was asked on Reddit but didn't get a response.

My main motivation to write xnotify wasn't blind dbus hating, as I have no opinion on dbus.
My main motivation was to play with I/O multiplexing. This is my first project using poll(2).

Done!

I just updated xnotify to the new version that support tags and string output.

Tags works like this:
You specify a tag with the TAG: option.
This will spawn a notification tagged as "music", and will close all other notifications tagged as "music".
Thus you can use a volume or album/song notification that will never repeat.

String output work like this:
First you have to invoke xnotify with the -b NUMBER button where NUMBER is a number from 1 to 5 specifying the mouse button that will trigger the string output, and pipe the xnotify stdout to a script you made. The -b option can be omitted, in which case the button will be button 3 (the right button).
Then you create a notification with the CMD: option.
Thus, when you click on this notification with the right mouse button, xnotify will pipe the string "next" to your script (which, in this example, will make mpc play the next song).

(27-10-2020, 02:09 PM)phillbush Wrote: My main motivation to write xnotify wasn't blind dbus hating, as I have no opinion on dbus.
My main motivation was to play with I/O multiplexing. This is my first project using poll(2).

Cool. And yeah, I'm not sure what u/ndgnah was on about but they seemingly aren't interested in your reasons :P

For what it's worth, there is currently an active thread over on the UnitedBSD forums where some NetBSD devs are taking requests for programs to package for NetBSD. So far they've been very responsive.
I've requested that xnotify be packaged (primarily in pkgsrc/wip) for testing. One user suggested I look into xmessage instead, stating it is "more minimal" however I think notify is a good balance between nice features and minimalism.

Do you have any thoughts on this? do you foresee xnotify being maintained long-term?

(27-10-2020, 08:18 PM)Ramiferous Wrote: Cool. And yeah, I'm not sure what u/ndgnah was on about but they seemingly aren't interested in your reasons :P

For what it's worth, there is currently an active thread over on the UnitedBSD forums where some NetBSD devs are taking requests for programs to package for NetBSD. So far they've been very responsive.
I've requested that xnotify be packaged (primarily in pkgsrc/wip) for testing. One user suggested I look into xmessage instead, stating it is "more minimal" however I think notify is a good balance between nice features and minimalism.

Do you have any thoughts on this? do you foresee xnotify being maintained long-term?

Yeah, I want to maintain xnotify in the long-term.
It is has been a fun project in which I applied some techniques I learned and it's been so easy to maintain.

As for xmessage, I don't see why one would use it for notifications: it does not stack one instance above the other like most notification systems do. But yeah, you can use it, but you will lost notification stacking, xft fonts, image support, notification grouping/tagging, etc. Imagine using xmessage to notify that your laptop battery is low...

I would use xmessage for dialogs or wizards, like how the good old wmii window manager did.

And xnotify is packaged in pkgsrc/wip,
but it's the old version that does not include the features I added that I mentioned in the other post.

(27-10-2020, 09:19 PM)phillbush Wrote: As for xmessage, I don't see why one would use it for notifications: it does not stack one instance above the other like most notification systems do. But yeah, you can use it, but you will lost notification stacking, xft fonts, image support, notification grouping/tagging, etc.

Great explanation.

(27-10-2020, 09:19 PM)phillbush Wrote: And xnotify is packaged in pkgsrc/wip,
but it's the old version that does not include the features I added that I mentioned in the other post.

Oh damn, I didn't even think to look first! lol
Perhaps I'll see if the maintainer of the pkgsrc/wip package is happy to update it.

(27-10-2020, 09:29 PM)Ramiferous Wrote: Is the pkgsrc/wip package maintained by you also? if so do you plan to update it?

No, it's not maintained by me.
But I am really thankful of whoever random guy on the Internet that appreciated my work to the point of maintaining a package for it. There are other works of mine in pkgsrc/wip (and on the Guix repo too).

I just realized that notifications appear on top of fullscreen windows.
I will make xnotify detect when the active window is fullscreen and apply one of the following behaviors.

For people who use other notification systems, what happens when you have a window in fullscreen?
• Does the notification is ignored and never appears?
• Does the notification is queued and appears when the fullscreen window become normal-sized or is closed?
• Or does the notification appears on top of the fullscreen window anyways?

Which behavior do you prefer in a notification system?

I'm using notify-send/dunst. Quick test shows a popup on top of fullscreen.

I use a custom one i hacked together and normally notifications appear above fullscreen windows. I have a keybinding that "pauses" all notifications, and after I hit it again they are replayed. This is good for e.g. doing presentations. Maybe that'd be useful behaviour?

(31-10-2020, 09:49 PM)phillbush Wrote: Which behavior do you prefer in a notification system?

I'm not fussed, but I wouldn't really want notifications popping up when I'm watching movies fullscreen etc

(01-11-2020, 08:48 AM)mcol Wrote: I use a custom one i hacked together and normally notifications appear above fullscreen windows. I have a keybinding that "pauses" all notifications, and after I hit it again they are replayed. This is good for e.g. doing presentations. Maybe that'd be useful behaviour?

That sounds cool!

(27-10-2020, 09:34 PM)phillbush Wrote: But I am really thankful of whoever random guy on the Internet that appreciated my work to the point of maintaining a package for it.

Pin, he is very dedicated to bringing NetBSD to the desktop and thus is helping to import and maintain packages that are requested (many by me) or seen as helpful to the user experience. I'll pass on your regards to him. :)

It was less than 4 months ago that NetBSD had no Spotify client at all and now, thanks to Pin, we have ncspot and Spotify-qt. He doesn't even use Spotify! haha

I'll also say that, while I never insisted on anyone else fixing a package that doesn't build on NetBSD, as soon as you tell the NetBSD devs that a package doesn't build correctly (and that it's not the users fault), they get quite determined to make it work. It's a great community.

(01-11-2020, 08:23 PM)Ramiferous Wrote: Pin, he is very dedicated to bringing NetBSD to the desktop and thus is helping to import and maintain packages that are requested (many by me) or seen as helpful to the user experience. I'll pass on your regards to him. :)

It was less than 4 months ago that NetBSD had no Spotify client at all and now, thanks to Pin, we have ncspot and Spotify-qt. He doesn't even use Spotify! haha

Oh, thanks to passing my regards!
I noticed that he also doesn't use notifications at all, but is still maintaining my notification system, which is very nice of him.

(01-11-2020, 08:23 PM)Ramiferous Wrote: I'll also say that, while I never insisted on anyone else fixing a package that doesn't build on NetBSD, as soon as you tell the NetBSD devs that a package doesn't build correctly (and that it's not the users fault), they get quite determined to make it work. It's a great community.

When I moved from Linux to BSD, I was uncertain about Open or Net, Open won me by their manpages. But NetBSD is certainly a good OS with a great community.

(01-11-2020, 08:48 AM)mcol Wrote: I use a custom one i hacked together and normally notifications appear above fullscreen windows. I have a keybinding that "pauses" all notifications, and after I hit it again they are replayed. This is good for e.g. doing presentations. Maybe that'd be useful behaviour?

Which notification system do you use and how do you set a keybinding to pause it?
Maybe that isn't the solution as I want to keep xnotify simple and don't make it listen to key presses.
Maybe using signals to pause/unpause notifications?

(31-10-2020, 09:49 PM)phillbush Wrote: • Does the notification is queued and appears when the fullscreen window become normal-sized or is closed?

I was trying all alternatives and this one is the trickiest and less appealing one:
I have to watch the root window for property changes so xnotify can be aware of the active window, and I also have to watch this active window for property changes on the WM state property for xnotify to be aware of whether it is fullscreen or not.
Maybe using signals is the way to go.

(01-11-2020, 09:49 PM)phillbush Wrote: I noticed that he also doesn't use notifications at all, but is still maintaining my notification system, which is very nice of him.

Yes, exactly! haha

(01-11-2020, 09:49 PM)phillbush Wrote: When I moved from Linux to BSD, I was uncertain about Open or Net, Open won me by their manpages. But NetBSD is certainly a good OS with a great community.

I was won by the willingness of NetBSD's developers to innovate and accept necessary changes to the base system. My personal feelings about OpenBSD is that there are too many chef's in the kitchen and not everyone can agree on what the recipe should be. I sense that it is harder to make innovations/changes, especially if it means getting rid of redundant software in base. But this is only from the outside looking in. I haven't used OpenBSD and my feelings should be taken with some salt. It's obviously very popular for a reason :)

(01-11-2020, 09:49 PM)phillbush Wrote: Which notification system do you use and how do you set a keybinding to pause it?
Maybe that isn't the solution as I want to keep xnotify simple and don't make it listen to key presses.
Maybe using signals to pause/unpause notifications?

The code for it is here but it might not be super useful as it is a long-running notification service rather than just the window-drawing side. It is a plugin for Qtile, which deals with the key-listening internally, so it is easy to bind methods to keys to pause and unpause notifications. For xnotify you could check for a "backlog" file before drawing windows. If it doesn't exist, notifications aren't paused, draw the window; if it exists, append the notification data to the backlog and exit. Then add a pause argument to create that file, and an unpause argument to go through it and replay the notifications that were redirected there. That might be a simple implementation :)