Should have builtin actions support

[Bastien Nocera]

(See also bug #542059)

notify-osd is the only notification-daemon around that doesn't support actions (I count KNotify, gnome-shell's implementation, notification-daemon's implementation and xfce-notifyd as the ones I know).

Instead of making application developer's life painful (by requiring them to implement fallbacks for the sake of notify-osd), notify-osd should implement the fallback itself.

It should be fairly easy for notify-osd to create a GTK+ dialogue itself, and destroy it when the notification is dismissed.

This would solve problems with existing software, or cleanups done in the GNOME stack in recent versions.

See also:
https://bugzilla.gnome.org/show_bug.cgi?id=575905

[Dylan McCall (dylanmccall)]

This discussion pops up a lot. The fact is, the Notifications spec includes actions as an optional feature that the notifications server does not need to support. It is up to the client to handle that situation, and at this point most existing clients do. I agree, this is terrible from an ecosystem standpoint (nobody wants to devote 50+ lines of code and multiple translated strings to generate special notifications for servers with and without certain capabilities), but this also isn't really the sort of thing that can be approached as a concrete bug to fix. It's a design decision, made quite a while ago, and if we want to debate it I think that should be done in a suitable discussion forum. If you want a concrete bug, I think the bug is that the notifications spec is getting increasingly painful thanks to the proliferation of optional server capabilities. (I guess there's another issue that Notify OSD's existing fallback dialog is practically user-hostile at times, but that's also kind of separate from this).

Please do bring this up on Freedesktop.org, and the the Unity mailing list if you feel this affects Unity. Keep in mind you aren't the first to suggest this for Notify OSD, though, so you may want to check out past discussions as well. Some code or mockups based on the existing design at http://wiki.ubuntu.com/NotifyOSD could go a long way, if you have the time.

[Bastien Nocera (hadess-deactivatedaccount)]

You don't want to implement this for all apps, fine by me. But let me put this another way:
- gnome-settings-daemon and vino are GNOME components, and they're made to work with gnome-shell
- gnome-shell supports actions
- so there's no need to implement a fallback in those core GNOME components

So you could use that same proposal I made in comment 0, and only apply it to known core components by checking their well-known D-Bus names, eg. if the client is "org.gnome.SettingsDaemon", implement actions internally.

That would save you from patching gnome-settings-daemon, vino and other core GNOME components you're re-using, with minimal work in notify-osd.

I'm not going to bring this up on the fd.o lists, as this is an Ubuntu/notify-osd specific problem, or on the Unity list, as I have no vested interest in making Unity better. I'm speaking as the downstream maintainer for a project you reuse. If you're not willing to implement this, you're merely deflecting the work from you to the gnome-settings-daemon Ubuntu maintainers.

[Matthew Paul Thomas (mpt)]

Notify OSD produces fallback alert boxes when applications don't bother to follow the spec <https://wiki.ubuntu.com/NotifyOSD#alert>, though they don't look very good because (for example) they use the binary name as their title.

But the linked bug report is about Sticky Keys. And as Dylan, Federico, and I all pointed out in that same bug report years ago, the Sticky Keys question isn't an asynchronous notification and so shouldn't be using the notification API in the first place. I even designed replacements. <https://wiki.ubuntu.com/NotifyOSD#keyboard-accessibility>

[Bastien Nocera (hadess-deactivatedaccount)]

> Notify OSD produces fallback alert boxes when applications don't bother to follow the spec
> <https://wiki.ubuntu.com/NotifyOSD#alert>

They don't bother to follow the notify-osd spec because they're not built for notify-osd but for gnome-shell's notifications.

As for using a dialog, it would break the use case Federico mentioned even more (as a system dialog should be modal, or at least always on top) and would break the "i'm dragging something in a drawing program" use case.

You're more than welcome to reopen the original bug if you feel strongly about it. In the meanwhile, I guess that somebody will have to reimplement the gnome-settings-daemon code to match the notify-osd code.

[Dylan McCall (dylanmccall)]

These are not Notify OSD notifications or GNOME Shell notifications in the
first place. The standard specification whose dbus interface you are using
is called the Desktop Notifications Specification. I still fail to see why
an application misusing the notifications spec is considered acceptable in
this case. It sounds to me like gnome-settings-daemon is being a bad
citizen. Embrace/Extend/Extinguish is not a methodology people should be
following in free software.
(Not that I think you're doing that _intentionally_, but it seems like a
pretty good analogue. Also, I wouldn't mind if someone did extinguish that
specification and replace it with two cleaner ones, but it would probably
be better to do that as a widely collaborative effort).

For what it's worth, even the draft for notifications 1.2 explains how
actions are optional, the server can ignore them, and this is (for reasons
of portability as well as maintainability) the client's problem:
http://developer.gnome.org/notification-spec/

If the specific issue is you don't want to bother maintaining code that
isn't core to GNOME 3, I think that is reasonable, and I think that could
add additional weight behind the existing downstream GSD bug report. Debian
patches exist for this :)