Emit the ActivationToken signal

[VixieTSQ]

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.

[lucalabs-de]

We should probably also emit the NotificationClosed signal while we're at it. Would you be willing to open another PR for this? Then I would implement #11 and #12.

[VixieTSQ]

We should probably also emit the NotificationClosed signal while we're at it. Would you be willing to open another PR for this? Then I would implement #11 and #12.

Sure! I'll work on this soon.

[VixieTSQ]

After a bit of investigation, generating an xdg activation token seems pretty complicated, and there's no good examples of it. It looks like we would have to interact with the wayland protocol, but I can't find any maintained haskell libraries for that. So I'm a little stuck on this.

On another note, maybe #8 is also because we don't list the signals in our introspection thingy (mostly because I can't figure out how to)

[lucalabs-de]

On another note, maybe #8 is also because we don't list the signals in our introspection thingy (mostly because I can't figure out how to)

I think it's just the key interfaceSignals (see https://hackage.haskell.org/package/dbus-1.3.2/docs/DBus-Client.html#t:Interface) which takes an Array of Signals. This is a different class from the one you emit; you should just be able to construct it as Signal "SignalName" [...], where [...] is an array of SignalArgs that you can construct similarly.

[lucalabs-de]

After a bit of investigation, generating an xdg activation token seems pretty complicated, and there's no good examples of it. It looks like we would have to interact with the wayland protocol, but I can't find any maintained haskell libraries for that. So I'm a little stuck on this.

I found this library: https://github.com/sivertb/wayland-wire. Although it's quite old and for some reason not on Hackage, it seems to do what we need. It takes an XML protocol specification and generates the corresponding Haskell bindings (using TemplateHaskell, which can do compile-time metaprogramming). The XML spec for the activation protocol should be https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/staging/xdg-activation/xdg-activation-v1.xml.

I haven't 100% understood yet how to use the library though. Also I'm not an wayland, so I can't really experiment with it either. Are you on wayland?

We would also need to figure out whether X11 or Wayland is running, this seems to be the most promising approach for that. Alternatively we could use compile flags and Haskell's CPP extension, but that makes the build process more complicated and might become problematic if we eventually want to upload this package to the AUR or similar.

This mentions some sort of interoperability with X11 tokens (which are easy to create), but I'm not sure if this implemented in every compositor.

[VixieTSQ]

I haven't 100% understood yet how to use the library though. Also I'm not an wayland, so I can't really experiment with it either. Are you on wayland?

Hey! Unfortunately I switched over to AGS, so I won't be able to work on this anymore. Apologies :(