Xpra: Ticket #407: handle .xpra file associations on osx

We already have this on win32 and Linux, so it makes sense to add it to osx.


Thu, 08 Aug 2013 14:37:35 GMT - Antoine Martin: description changed

Thu, 08 Aug 2013 14:38:44 GMT - Antoine Martin: attachment set

first attempt at making a new Info.plist with UTExportedTypeDeclarations

Tue, 02 Jun 2015 10:54:03 GMT - Antoine Martin: status changed

I think this depends on #641.

Fri, 04 Sep 2015 07:49:08 GMT - Antoine Martin:

scheduling for 0.16

Fri, 13 Nov 2015 13:39:38 GMT - Antoine Martin: milestone changed

Sun, 10 Apr 2016 06:05:40 GMT - Antoine Martin: milestone changed

Blocked by #641.

As per http://stackoverflow.com/a/18988753/428751, lsregister can be useful:

alias lsregister='/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister'
lsregister -lint -f ./Xpra.app
lsregister -dump -f ./Xpra.app

Tue, 12 Apr 2016 16:32:17 GMT - Antoine Martin: attachment set

file association works with this file - but OSX hides the actual filename somewhere else, of course

Wed, 13 Apr 2016 07:14:20 GMT - Antoine Martin: owner, status changed

Done in r12380. Can easily be tested by double-clicking on a session file like this one:


The OSX client should be launched and connect to the given server. Will follow up in #1163 for handling xpra://username@HOST:PORT/ urls on osx.

@afarr: not sure you really care about this use case, though it might be useful for easily connecting to servers by pre-defining some commonly used session files and leaving them on the desktop.

Wed, 13 Apr 2016 19:22:50 GMT - alas: owner changed

Hmm... setting up a test.xpra file with the above content (with more appropriate numbers) in a clickable place... double clicking launches the launcher, but doesn't connect until I then click the launcher's connect button.

0.17.0 r12380 client against fedora 23 server.

Initial launch attempt prompted me with a “Xpra” can’t be opened because it is from an unidentified developer., not-unexpected, message... after going through rigamarole to allow Xpra to run, the initial attempt launched the launcher with empty fields.

Second double-click triggered the launcher firing with the fields filled, but still required a button click.

Third try, though (after having successfully connected on the previous try) worked as expected.

Passing this back to you in case there're any details I missed... but looks ready to close.

Thu, 14 Apr 2016 04:20:20 GMT - Antoine Martin: status changed; resolution set

FYI: the order of the options in session files does not matter. (and you can also specify encoding, etc..)

I did try to connect without a password and the launcher dialog did show up, with an error showing "connection timed out". I guess we should try to capture the real reason for the failure ("missing / wrong password"), but this will do for now.

Fri, 15 Apr 2016 02:56:09 GMT - Antoine Martin: milestone changed

Sun, 14 Oct 2018 05:39:46 GMT - Antoine Martin:

Painful updates to this ugly code done in r20670 for #1762.

Sat, 23 Jan 2021 04:54:31 GMT - migration script:

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