Xpra: Ticket #1163: handle xpra:// urls on osx

Follow up from #407.

Unfortunately gtk-osx does not wrap the openURL signal. So we will need to implement this with the application delegate code..

This is all really ugly and does not fit well at all with the way the code is implemented at present: every other platform will give us the file or URL to open as soon as we start the process. Not so on OSX, where we need the event loop to be running before we can get this information using a signal, sigh. r12380 worked around this for "open-file", it's ugly but it works.

"open-url" currently fires the launcher (as it lives in the same info.plist), maybe we can just hack this class further to launch the regular client with the URL. It's not going to be pretty.

Tue, 12 Jul 2016 16:52:22 GMT - Antoine Martin: milestone changed

Milestone renamed

Wed, 10 Aug 2016 04:37:43 GMT - Antoine Martin: status changed

See #1277: osx delegate error

Thu, 25 Aug 2016 16:20:02 GMT - Antoine Martin: owner, status changed

Better links:

Done in r13463 (and found a bug along the way).

For testing on OSX, click on an xpra link in a browser or just run:

open xpra://HOST:IP/?encoding=rgb

@afarr: this is just a FYI, feel free to close.

Tue, 06 Sep 2016 21:28:25 GMT - alas: owner changed

I tried to test from the MacOS directory of a 1.0 r13590, but couldn't seem to get this to work (though, admittedly, I'm not sure what this is supposed to do, exactly).

Running open https://github.com/Xpra-org/xpra/issues/1290 opens a trac ticket in my default browser, as expected.

Running open xpra://xpra.org/trac/ticket/1290, on the off chance this might be what you mean by "an xpra link", fails.

Setting up a server with --html=on and then trying open xpra://server-ip:port/?encoding=rgb causes the terminal window to get my hopes up by flashing like it is going to do something, but then disappoints me by not succeeding at anything.

Trying to just enter xpra://server-ip:port/?encoding=rgb into a browser triggers a google search, as does trying xpra://xpra.org/trac/ticket/1257.

I'm not sure we have any intention to use this feature, so you could close if you'd like... but if there's some glaringly obvious detail that I'm missing, let me know and I can test some more.

Wed, 07 Sep 2016 02:57:34 GMT - Antoine Martin: owner changed

@afarr: this is for connecting to an xpra server (not a web URL). You don't need to run it from a specific directory as long as you have installed the latest PKG on that OSX system. You do not need to run the server with "html=on". This also works on Linux, just replace "open" with "xdg-open". This also works on win32, you can type it in the URL bar of a browser.

If you saw a "disconnect of the other session", then it is (almost) working. Maybe a different bug is causing a logging packet to be sent before the connection is fully established. r13592 will now log the full "unknown or invalid" packet data with "-d network". We want to know what that packet contains so we can prevent it, as this could cause us problems even without using the URL handler for launching. This message can also occur if the client is disconnected for another reason, but this should have been logged already - please include the full server output.

Fri, 30 Sep 2016 17:14:38 GMT - J. Max Mena: status changed; resolution set

Tested with the latest r13937.pkg:

open xpra://ip:port will connect to an Xpra session, if it exists. Feeding it an invalid URL (such as lacking a port) will just open the launcher. If no Xpra server is at a valid ip:port combo, the launcher also opens, but this time giving an error.

NOTE: Connecting to a ip:port combo that doesn't have a server after already having a session will close the first session.

The dozens? of OSX users will be pleased.


repro step:

Doing so disconnects the first session.

Sat, 23 Jan 2021 05:16:42 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1163