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.
See #1277: osx delegate error
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:
@afarr: this is just a FYI, feel free to close.
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).
open https://github.com/Xpra-org/xpra/issues/1290 opens a trac ticket in my default browser, as expected.
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
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.
open xpra://10.0.32.134:1203/?encoding=rgb(ip & port of my server today), which still doesn't open anything in a default browser, but it did trigger a disconnect of the other session and a
unknown or invalid packet type: logging from Protocol (tcp socket: server-ip <- client-ip:some-random-number-I-presume-is-a-wss-socket)error on the server side.
@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.
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.
Doing so disconnects the first session.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1163