handle .xpra file associations on osx

[Antoine Martin]

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

Links:

• ​Registering the File Types Your App Supports
• ​How do I register a custom filetype in iOS

[Antoine Martin]

first attempt at making a new Info.plist with UTExportedTypeDeclarations

[Antoine Martin]

I think this depends on #641.

[Antoine Martin]

scheduling for 0.16

[Antoine Martin]

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

[Antoine Martin]

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

[Antoine Martin]

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

host=192.168.0.1
port=10000
mode=tcp
autoconnect=true

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.

[alas]

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.

• Just out of curiosity (for extra-credit?) I also added a password=password line in the .xpra file, between the mode & autoconnect lines, and tried once more and it worked as expected also!

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

[Antoine Martin]

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.

[Antoine Martin]

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

[migration script]

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