streaming (waybar) support

[anarcat]

It would be nice to have a way to "stream" notifications out so that another app can get updates when notifications land.

Right now, I can find out the list of pending notifications with mako list. I can make a custom waybar panel, for example, that will count the number of such entries with something like: makoctl list | jq '.data[] | length', and I could integrate that in waybar.

But then I need to refresh this all the time, and that's costly (say, on battery), as I have to wakeup all the time. Meh.

A better way would be to have some sort of streaming interface where a caller could hook into mako and get pushed updates. The way sway-notification-center works in that regard is interesting. Look at the output of the --subscribe-waybar flag:

> swaync-client --subscribe-waybar
{"text": "0", "alt": "none", "tooltip": "", "class": "none"}

Now, that output is kind of specific to waybar of course: this is a JSON object formatted in a way that Waybar will like. But this could be anything you like... The blobs in the .data field of makoctl list would be fine, as an intermediate filter could parse those and generate the correct waybar output.

The key here is to have mako send those updates over a pipe somehow, instead of the callers pulling those in.

Right now, my mako integration in waybar is substandard, as the message count doesn't automatically update. But it's the best I could do with the current interface, it would be great to have a push system to improve on this!

    "custom/dnd": {
        "interval": "once",
        "return-type": "json",
        "format": "{}{icon}",
        "format-icons": {
            "default": "",
            "do-not-disturb": ""
        },
        "on-click": "makoctl mode -t 'do-not-disturb' > /dev/null; pkill -RTMIN+11 waybar",
        "on-click-right": "makoctl dismiss --all ; pkill -RTMIN+11 waybar",
        "exec": "mako-waybar-output",
        "signal": 11
    },

the exec (mako-waybar-output) is now a standalone script that looks like this:

#!/bin/sh

count="$(makoctl list | jq '.data[] | length')"
mode="$(makoctl mode | grep 'do-not-disturb' || echo default)"

if [ "$mode" != "default" ]; then
    class="$mode"
elif [ $count -gt 0 ]; then
    class="active"
fi

printf '{"text": "%s", "alt":"%s","tooltip":"mako notification mode: %s", "class": "%s"}' "$count" "$mode" "$mode" "$class"

I suspect something around dbus would be needed to implement this, but I'm not familiar enough with dbus (let alone mako's implementation) to figure this out..

Thanks!

[emersion]

Yeah, this would need a new event in the mako D-Bus interface. Alternatively, waybar could snoop at the D-Bus messages sent to org.freedesktop.Notifications (ala dbus-monitor), but seems like this would need some special permission rules.

[anarcat]

yeah, part of the problem i guess is that someone needs to monopolize that dbus interface... but even if i would snoop at that interface, i would need to do mako's counting of what notifications are active and what have been dismissed, I don't think that's available on dbus?

[anarcat]

note that i've updated my waybar config in the post above, i'll try to keep it updated as i go.

[emersion]

i would need to do mako's counting of what notifications are active and what have been dismissed, I don't think that's available on dbus?

You'd need to keep state inside a program to remember the number of notifications. You'd increase the count when a notification is created, and decrease when dismissed.

[anarcat]

On 2025-01-07 12:12:53, Simon Ser wrote: > i would need to do mako's counting of what notifications are active and what have been dismissed, I don't think that's available on dbus? You'd need to keep state inside a program to remember the number of notifications. You'd increase the count when a notification is created, and decrease when dismissed.

Yeah, that's why I'm proposing to have makoctl provide a way to expose that internal state. :)

[emersion]

#552 helps with this.

[Queuecumber]

I think even just having an on-dismiss binding would help with this. right now I have the following:

in waybar:

"custom/notification": {
            "format": "{icon}",
            "on-click": "makoctl mode -t summary",
            "on-click-right": "makoctl dismiss --all ; pkill -rtmin+5 waybar",
            "escape": true,
            "exec": "~/.local/bin/mako-scrape",
            "return-type": "json",
            "signal": 5,
            "format-icons": {
                "0": "",
                "1": "󰲡",
                "2": "󰲣",
                "3": "󰲥",
                "4": "󰲧",
                "5": "󰲩",
                "6": "󰲫",
                "7": "󰲭",
                "8": "󰲯",
                "9": "󰲱",
                "9+": "󰲳"
            }            
        },

mako-scrape:

#!/usr/bin/env python

import subprocess
import re
import json

notification_text = subprocess.run(["makoctl", "list"], capture_output=True).stdout.decode("utf-8")
match = re.findall(r"Notification \d+\:(.*)", notification_text)

response_struct = {
    "text": "",
    "alt": f"{len(match) if len(match) <= 9 else '9+'}",
    "tooltip": "\r".join([f"{i+1}: {m}" for i, m in enumerate(match)])
}

print(json.dumps(response_struct))

and mako config:

background-color=#000000D0
border-radius=15
font=FiraCode Nerd Font Mono Ret 10
progress-color=#76B900FF
text-color=#FFFFFFFF
default-timeout=0
max-visible=-1
border-size=0
on-notify=exec pkill -SIGRTMIN+5 waybar

[mode=summary]
invisible=1

So when a new notification comes in mako sends a signal to waybar which re-runs the scrape and updates the icon. The only thing that's missing is re-running the scraper when a notification is dismissed.

[Queuecumber]

I just submitted #578 with the on-closed event, it turned out to be very easy to add (the C api here is excellent)

Let me know if you think this is an acceptable solution. I think this event may be useful for some other things too.

Here is my updated mako config that shows how I used this to get waybar to update. It is fully functional after adding this notification.

background-color=#000000d0
border-radius=15
font=firacode nerd font mono ret 10
progress-color=#76b900ff
text-color=#ffffffff
default-timeout=0
max-visible=-1
border-size=0
on-notify=exec pkill -sigrtmin+5 waybar
on-closed=exec pkill -sigrtmin+5 waybar

[mode=summary]
invisible=1

[Queuecumber]

Well I've had quite an afternoon

I now have Waybar working with the DBus Notifications API I added in #579. The mako config requires no knowledge of waybar for this:

background-color=#000000D0
border-radius=15
font=FiraCode Nerd Font Mono Ret 10
progress-color=#76B900FF
text-color=#FFFFFFFF
default-timeout=0
max-visible=-1
border-size=0

[mode=summary]
invisible=1

Note that there isnt an on-notify event handler anymore.

The waybar config becomes:

  "custom/notification": {
    "format": "{icon}",
    "on-click": "makoctl mode -t summary",
    "on-click-right": "makoctl dismiss --all",
    "exec": "~/.local/bin/mako-scrape",
    "return-type": "json",
    "escape": true,
    "format-icons": {
      "0": "",
      "1": "󰎤",
      "2": "󰼐",
      "3": "󰼑",
      "4": "󰼒",
      "5": "󰼓",
      "6": "󰼔",
      "7": "󰼕",
      "8": "󰼖",
      "9": "󰼗",
      "9+": "󰼘"
    }
  },

No more using pkill to send signals.

The script ~'/.local/bin/mako-scrape now runs continuously in the background (Waybar supports this) and listens for the PropertyChanged event from Mako, each time it receives an event it prints a new line of JSON in the Waybar format and that is enough for Waybar to update.

This is the script:

#!/usr/bin/env python
import json
from pydbus import SessionBus
from gi.repository import GLib

loop = GLib.MainLoop()

bus = SessionBus()
mako_object = bus.get(
    "org.freedesktop.Notifications", 
    "/fr/emersion/Mako" 
)

def format_notification_for_waybar(notifications):
    response_struct = {
        "text": f"{len(notifications)}",
        "alt": f"{len(notifications) if len(notifications) <= 9 else '9+'}",
        "tooltip": "\r".join([f"{i+1}: {m['summary']}" for i, m in enumerate(notifications)]),
        "class": "has-notifications" if len(notifications) > 0 else ""
    }

    print(json.dumps(response_struct), flush=True)

def on_notifications_changed(iface, prop_changed, prop_invalidated):
    if 'Notifications' in prop_invalidated:
        format_notification_for_waybar(mako_object.Notifications)

format_notification_for_waybar(mako_object.Notifications)

with mako_object.PropertiesChanged.connect(on_notifications_changed):
    loop.run()

Note you need to have pydbus installed for this to work

[quite]

@Queuecumber looks very neat! hope #578 and #579 (was it right) can make it!

[anarcat]

@Queuecumber we wouldn't need #578 with you're latest incantation though, no?

i wonder if waybar could get some "native" dBus handler in waybar then... perhaps a generic thing, or maybe a mako module directly, that would be pretty neat.

otherwise, awesome work, @Queuecumber that's great to see!!

[Queuecumber]

we wouldn't need #578 with you're latest incantation though, no?

Correct, although I think #578 could be useful for other things I don't have strong feelings about it either way and you dont need it for this script

i wonder if waybar could get some "native" dBus handler in waybar then... perhaps a generic thing, or maybe a mako module directly, that would be pretty neat.

Yes I think this is possible, I thought about a generic dbus handler but that sounds really complicated, I probably wouldnt have time to do it. A mako specific one might be easier but I'm not sure what the likelihood of it being merged is

[anarcat]

I thought about a generic dbus handler but that sounds really complicated, I probably wouldnt have time to do it.

Agreed.

A mako specific one might be easier but I'm not sure what the likelihood of it being merged is

We could ask upstream, but they seem pretty enthusiastic about merging random things like this. :)