lucalabs-de / end Goto Github PK

Currently, it is possible to specify different notification types that can be selected by varying the end-type hint. It might be useful to additionally allow to show different notifications based on the calling application. The libnotify protocol already supplies an "Application Name" field, so this should be straightforward to implement.

One question is how to define this in the config, as currently the field notification-type.hint is mandatory.

The DBus notification specification includes this signal called ActivationToken which allows us to emit an activation token (Can be either an X11-style startup ID (see Startup notification protocol) or a Wayland xdg-activation token.)

The intent is to emit this signal before emitting the ActionInvoked signal, which tells the window manager to hand off focus to the application which created the notification associated with the action. An example of how this works is with Firefox. Say we get a Discord notification. When we tell end to invoke the default action with that Discord notification. It will first emit the ActivationToken which will cause the window manager to switch workspaces and focus Firefox. Then we emit the ActionInvoked which Firefox will take and switch tabs to Discord.

Instead of making the notification logic more complex, we simplify it by removing the option for custom notifications altogether. See this conversation: #5 (comment).

The same functionality can be achieved by querying the notification data inside yuck, using eww's expressions.

I have it so when I click on my notification in eww, it'll call end close <id>. But when the timeout for the notification is up and end tries to close it, it fails and crashes because the notification is already closed

Currently, hints are exposed to eww in the custom format "(key1, value1)(key2, value2)...". Since eww has JSON support, it might be easier to expose them as a JSON object.

Since JSON is nice to work with in eww's expressions, it would be cleaner to expose all notification data as a single JSON object instead of 7 different parameters.

The notification-frame window will flicker on every update from end. This is because end calls eww open even when the window is already open, which (oddly) causes the window to reload.

Cabal failed to resolve dependencies. I'm using version 3.6.2.1 of cabal.

Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: EwwNotificationDaemon-0.1.0.0 (user goal)
[__1] next goal: base (dependency of EwwNotificationDaemon)
[__1] rejecting: base-4.17.2.0/installed-4.17.2.0 (conflict:
EwwNotificationDaemon => base^>=4.16.4.0)
[__1] skipping: base-4.19.0.0, base-4.18.1.0, base-4.18.0.0, base-4.17.2.0,
base-4.17.1.0, base-4.17.0.0 (has the same characteristics that caused the
previous version to fail: excluded by constraint '^>=4.16.4.0' from
'EwwNotificationDaemon')
[__1] rejecting: base-4.16.4.0, base-4.16.3.0, base-4.16.2.0, base-4.16.1.0,
base-4.16.0.0, base-4.15.1.0, base-4.15.0.0, base-4.14.3.0, base-4.14.2.0,
base-4.14.1.0, base-4.14.0.0, base-4.13.0.0, base-4.12.0.0, base-4.11.1.0,
base-4.11.0.0, base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0,
base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1,
base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0,
base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2,
base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2,
base-3.0.3.1 (constraint from non-upgradeable package requires installed
instance)
[__1] fail (backjumping, conflict set: EwwNotificationDaemon, base)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, EwwNotificationDaemon

The example config in EXAMPLE.md still uses the old notification syntax and doesn't show how to work with notification images. Also, it might be useful to include the config as actual files instead of Markdown.