native OSX notifications

[totaam]

Issue migrated from trac ticket # 1305

component: client | priority: minor | resolution: wontfix | keywords: osx notifications

2016-09-13 07:36:22: antoine created the issue

---

See Notifications: replace the existing GTK notifier code with native macos notifications:

• NSUserNotification and NSUserNotificationCenter
• examples: notify.py, Working with Mountain Lion's Notification Center using PyObjC, Mac OS Notifications from Python

Maybe wait for the newer build environment (#840) to make it easier to test?

[totaam]

2016-09-13 12:44:55: antoine changed status from new to assigned

[totaam]

2016-09-13 12:44:55: antoine commented

---

I tried a quick test and there are issues with the notification code: NSUserNotificationCenter.defaultUserNotificationCenter() returns None in python and NSUserNotificationCenter.defaultUserNotificationCenter() returning None using PyInstaller.
The same code works when using the system installed python!
So we either have to fix this (not sure how) or use a subprocess... yuk.

[totaam]

2017-02-18 15:13:04: antoine uploaded file osx-notifications.patch (5.3 KiB)

try to use native code for notifications

[totaam]

2017-02-18 15:55:50: antoine commented

---

The notification center API just isn't accessible from our environment - no idea why, changing the CFBundleIdentifier (lowercase or whatever) does not help, neither does signing the app, installing using a PKG, etc..

We can run the exact same code from the system python interpreter though...
So the patch above attempted to load the notification center directly and when that fails resorts to running the same code using the system interpreter via exec. And that also fails mysteriously.
I even tried calling "osascript -e .." and using applescript via pyobjc. None of these solutions work.
I give up.

[totaam]

2017-11-14 14:09:15: antoine commented

---

See #1688

[totaam]

2017-11-26 14:08:34: antoine commented

---

Let's try again..

[totaam]

2017-12-28 08:30:03: antoine changed status from assigned to closed

[totaam]

2017-12-28 08:30:03: antoine set resolution to wontfix

[totaam]

2017-12-28 08:30:03: antoine commented

---

Found a partial solution here: [https://github.com/jaredks/rumps/issues/9#issuecomment-94320800]: I can also get this working by putting an Info.plist file directly into the same bin dir as my virtualenv's python.
No idea why we have to copy the Info.plist to yet another location, but that sort of fixes it: r17769.
We now have two new notifier helpers (both disabled by default since r17771):

• native: XPRA_OSX_NATIVE_NOTIFIER=1 xpra attach ..
• subprocess: XPRA_OSX_SUBPROCESS_NOTIFIER xpra attach ..

Also, all the notifications use the icon of the main process (xpra's) and we can't override it.
The "subprocess" one shows notifications every time, but we cannot cancel them (the process that generated them is short lived) and clicking on the application icon starts up a new xpra launcher...
The "native" one sort of works, but Apple decided that when the application already has focus, it will move the notifications directly to the notification center without first appearing on screen at all. (see [https://stackoverflow.com/a/25303802/428751])
So that makes the notifications completely useless to us, and I don't see any easy workaround for it: spawning a daemon app (one that would never get focus) could lead to all sorts of other problems (hard to implement callbacks, or send focus back to main xpra process, etc) and I'm not even sure we can have notifications in a non-gui app (one that does not have an icon in the dock).

At this point, the only potential solution that I can think of is #1727: "dock icon per forwarded application"

For testing, one can generate notifications without using a specific application on the server:

xpra control :10 send-notification 0001  'notification title' 'notification message' '*'
xpra control :10 close-notification 0001 '*'