#407 closed task (fixed)
handle .xpra file associations on osx
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | minor | Milestone: | 0.17 |
Component: | platforms | Version: | |
Keywords: | osx | Cc: |
Description (last modified by )
We already have this on win32 and Linux, so it makes sense to add it to osx.
Links:
Attachments (2)
Change History (12)
comment:1 Changed 7 years ago by
Description: | modified (diff) |
---|
Changed 7 years ago by
Attachment: | Info.plist added |
---|
comment:4 Changed 5 years ago by
Milestone: | future → 0.16 |
---|
comment:5 Changed 5 years ago by
Milestone: | 0.16 → 0.18 |
---|
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
Changed 5 years ago by
Attachment: | Info.2.plist added |
---|
file association works with this file - but OSX hides the actual filename somewhere else, of course
comment:6 Changed 5 years ago by
Owner: | changed from Antoine Martin to alas |
---|---|
Status: | assigned → new |
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.
comment:7 Changed 5 years ago by
Owner: | changed from alas to Antoine Martin |
---|
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.
comment:8 Changed 5 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.
comment:9 Changed 5 years ago by
Milestone: | 0.18 → 0.17 |
---|
first attempt at making a new Info.plist with UTExportedTypeDeclarations