xpra icon
Bug tracker and wiki

Opened 19 months ago

Closed 4 months ago

#1305 closed enhancement (wontfix)

native OSX notifications

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: minor Milestone: 2.3
Component: client Version: trunk
Keywords: osx notifications Cc:

Description

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

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

Attachments (1)

osx-notifications.patch (5.3 KB) - added by Antoine Martin 14 months ago.
try to use native code for notifications

Download all attachments as: .zip

Change History (6)

comment:1 Changed 19 months ago by Antoine Martin

Milestone: 1.0future
Status: newassigned

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.

Changed 14 months ago by Antoine Martin

Attachment: osx-notifications.patch added

try to use native code for notifications

comment:2 Changed 14 months ago by Antoine Martin

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.

comment:3 Changed 5 months ago by Antoine Martin

See #1688

comment:4 Changed 5 months ago by Antoine Martin

Milestone: future2.3

Let's try again..

comment:5 Changed 4 months ago by Antoine Martin

Resolution: wontfix
Status: assignedclosed

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 '*'
Note: See TracTickets for help on using tickets.