Notification support

[Timidger]

Notifications should be able to be spawned both internally by Way Cooler and externally by D-Bus clients.

Eventually, it would be nice to have a way to swap out the notification system so that the user can provide their own D-Bus powered client program to draw the notifications. It will default to the in-build Way Cooler one if one is not set.

For now though, this is only tracking the feature to have notifications at all.

[bennofs]

Why does this feature need to be integrated into way-cooler? Would it no be easier to rely on the existing org.freedesktop.Notifications DBUS API? (https://developer.gnome.org/notification-spec/)

[Timidger]

Oo, thanks for bringing that to my attention. I should have searched around more for a standard API. I'll attempt to implement that instead as that will let other programs, such as zenity work with Way Cooler.

[hedning]

There's wayland wall which have a protocol extensions for notifications, where eventd is a client which supports the freedekstop notification standard. So might be easiest to implement the notification-area from wayland-wall.

[Timidger]

@hedning Hm, according to orbment-wall the protocols can be injected into wlc using a shared library hack. I tried doing that with Way Cooler, and though they are advertised nothing seems to happen (tested the ww-background example, which did nothing, and tried to play around with eventd but couldn't figure out how to make it spawn anything).

I'll keep that project in mind though, thanks for bringing it up.

EDIT: Silly me, looks like I'd need to do some work to have that work, similar to this proposed PR on sway. Though that's an old PR, and it looks like from the project page it should just work through injection... pinging @sardemff7 for more details

[sardemff7]

The injector should need no special work from the compositor. If the interface is advertised, it should work. ww-background is not the perfect one to test with, since there are several ways the redraw of the background could be hidden by the internal feature of the compositor. eventd should need little work, but the lack of error message does not mean you should see something, since it uses several backends and no connected backend is not an error. rofi is a better test, as (currently) you can only build one backend at a time.

The injector is just the easy not-code-invasive way to support this protocol (and others), but direct support in the compositor is better. You can use the files from orbment-wall to easily integrate with any WLC-based compositor. The API is a context struct and a few calls to put in WLC hooks.

I’m building Way Cooler to test, we’ll see.

Edit: to test eventd, running env -u DISPLAY WAYLAND_DISPLAY=wayland-0 eventd should work. Default build options have nd plugin and its Wayland backend built. But to run it from the build dir is another matter, you need a few more env vars.

[sardemff7]

Just tested, the injector works, but notifications are not well handled because Way Cooler does not check if the surface should be tiled or not. You can see here that I set the UNMANAGED and OVERRIDE_REDIRECT types. And Sway handle them here, for example, though it’s not perfect. (rofi would better fit UNMANAGED than OVERRIDE_REDIRECT, but it cannot get focus with UNMANAGED.)

[Timidger]

Moving this to a later release, since we have basic notifications with @sardemff7's project, and that we have fixed the UNMANAGED issue with #302.

Eventually we will have Way Cooler specific notification support, probably via a wayland protocol.

[sardemff7]

My WLC injector really is a hack, and native support in compositors would be better and more stable. The code should be easily hookable already, used as a git submodule.

I’m not quite sure what you mean with “Way Cooler specific notification support, probably via a wayland protocol”. If it’s for notification daemons, why do you need a specific protocol when there is one working already? If it lacks anything you’d need, it’s probably better to discuss adding features to it. However it sounds like a client-to-WayCooler protocol, which is weird since your initial feature is about using a D-Bus protocol, so I guess the Freedesktop.org one.

Just in case, a little summary of the current state: There are already 3 D-Bus notifications protocols (Freedesktop.org, GNotification and KNotify), 2 network notifications protocols (GNTP from Growl and SNP from Snarl) and 1 network more-than-notifications protocol (EvP from eventd). (There are a bunch more, but more restricted, private or not targeted to desktop, and the new Windows and OSX ones.) The Wayland part is just about getting the surfaces to display, and considering the complex layouts some software support (specifically eventd, Growl and Snarl), I went the simplest way, yet Wayland-compliant (a compositor can restrict the area to a corner, and clients have to deal with it, eg. by displaying only one notification at a time). AFAIR, there is a Freedesktop.org-to-KNotify gateway somewhere, eventd supports EvP, Freedesktop.org (with plans to support GNotification in a near future and KNotify, GNTP and SNP in a far future), and others just support one of them. eventd can also forward its own internal events to the Freedesktop.org D-Bus protocol. Freedesktop.org, via libnotify (and the fallback in GNotification) is the most used protocol in existing clients.

[Timidger]

@sardemff7

Ah thanks, I commented on that way too late last night and thus forgot to re-immerse my self in the issue. My first thought was compatibility with other compositors, most notably Sway, but supporting multiple ways to display notifications is more important.

Using the standard Freedesktop.org notification protocol is probably what I'll end up going with, as that's much more standard and easier to implement.

[sardemff7]

At least that would provide you the feature, since Sway is going the X11 way to have one protocol to fit them all. But I didn’t lose hope yet that they would just use Orbment Wall implementation as a git submodule eventually. If you ever use Orbment Wall code, or a variant of it, don’t hesitate to ping me for help understanding it. Or if you have any feature request to improve the code or the protocol.