#2641 closed defect (fixed)
xdg-open bugs / improvements
Reported by: | stdedos | Owned by: | stdedos |
---|---|---|---|
Priority: | minor | Milestone: | 4.0 |
Component: | server | Version: | 3.0.x |
Keywords: | Cc: |
Description
Since you already use a non-standard xdg-open implementation, would you consider adding support for multiple arguments?
xpra:
$ xdg-open xpra-info-0-2617.log xpra-info-2-2617.log $ echo $? 0 $
Showing one file
vs Xenial:
$ xdg-open xpra-info-0-2617.log xpra-info-2-2617.log xdg-open: unexpected argument 'xpra-info-2-2617.log' Try 'xdg-open --help' for more information. $ echo $? 1 $
Transfers:
- Download (for some reason) does Download & Open, and closes the transfers window
- Add an Open Download Directory
Change History (8)
comment:1 follow-up: 2 Changed 12 months ago by
Owner: | changed from Antoine Martin to stdedos |
---|
comment:2 Changed 12 months ago by
Replying to Antoine Martin:
xdg-open: unexpected argument 'xpra-info-2-2617.log'
The manual page for
xdg-open
shows: xdg-open {file | URL}, xdg-open - opens a file or URL in the user's preferred application.
So using multiple arguments is not meant to work. Don't do that.
I said:
Since you already use a non-standard xdg-open implementation,
Well, you could internally invoke it multiple times or fail like the original implementation
Either way works for me, as it will be "as-defined or better".
Now it has this semi-defined behavior "I'll parse only $1, warn/fail nothing, and return ok"
Download (for some reason) does Download & Open, and closes the transfers window
If you allow remote-open, the request to open the file will be forwarded. See
open-files
andopen-url
options.
I am confused:
--open-files=on|off This option may be used to allow the remote end to automatically open files after they have been uploaded. This may be a security risk if you are using xpra to constrain what the clients can execute on the server.
You sound like this is a client option; this sounds like a server option, and it also references upload.
Executing xdg-open $1
in an xpra server allows the client to download the file.
Add an Open Download Directory
Hmm. Don't all desktop environments have a shortcut for that already?
And browsers too :-D
comment:3 follow-up: 4 Changed 12 months ago by
Updates:
- r25635 support --help, --manual and --version command line arguments
- r25636 error out unless we get a single argument
- r25639 adds a 'show downloads' button
Download (for some reason) does Download & Open, and closes the transfers window
Ah, finally spotted the problem - sorry it took so long.
Fixed in r25640: we should not show 'Download' when the request is for opening the file, since we can't do that: accepting the request will 'Download and Open'. (this is for backporting to v3)
The better fix is in r25641 (v4 only - maybe in v3.1 eventually): the GUI can now override the request and just 'Download' a file that was meant to be opened.
I am confused:
You sound like this is a client option; this sounds like a server option, and it also references upload.
It is both a client and server side option.
File transfers can go both ways, but not all options make sense at both ends, ie: the client has a GUI for asking for confirmation, the server does not.
@stdedos: there are beta windows builds with the download-only fix.
comment:4 Changed 12 months ago by
Replying to Antoine Martin:
Updates:
- r25635 support --help, --manual and --version command line arguments
A "philosofical" discussion here: Why not accept -h
/ -v
?
I've seen a lot projects (GNU) doing that; I understand if your tool is less
(that has a metric ton of arguments) that you don't want to "waste" a potential flag; why not do it on a tool that accepts so little arguments?
I can understand you'd like to use e.g. -v
for verbose, but -h
?
- r25636 error out unless we get a single argument
In my eyes, you did this ^^^ in the previous commit; here you removed the now-unneeded loop :/
- r25639 adds a 'show downloads' button
Thank you :-D
Download (for some reason) does Download & Open, and closes the transfers window
Ah, finally spotted the problem - sorry it took so long.
Fixed in r25640: we should not show 'Download' when the request is for opening the file, since we can't do that: accepting the request will 'Download and Open'. (this is for backporting to v3)
The better fix is in r25641 (v4 only - maybe in v3.1 eventually): the GUI can now override the request and just 'Download' a file that was meant to be opened.
I am confused:
You sound like this is a client option; this sounds like a server option, and it also references upload.
It is both a client and server side option.
File transfers can go both ways, but not all options make sense at both ends, ie: the client has a GUI for asking for confirmation, the server does not.
I am not sure if I have thought of everything; why server can't just do "whatever it's allowed to do", and allow the client to hint the server what to do?
In Evolution (also the mainstream Xenial one), there is the Add Attachment action in Compose mail. When that opens, Nautilus has this "open as read-only" extra flag. I believe that Evolution "instructs" Nautilus to show that.
Likewise, xpra-client can have the "Open file after uploading" flag, and the server can decide to honor client's hint if allowed to.
You could go one step further and disable that on the client, if server publishes that it's not allowed to open arbitrary files/urls.
@stdedos: there are beta windows builds with the download-only fix.
I'll give it a go tomorrow or Monday.
comment:5 Changed 12 months ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
A "philosofical" discussion here: Why not accept -h / -v?
The regular xdg-open
this overrides does not.
This script tries to be indistinguishable.
Likewise, xpra-client can have the "Open file after uploading" flag, and the server can decide to honor client's hint if allowed to.
That's already the case - pretty much: start your server with --open-files=yes
and the client file chooser dialog gains an extra 'Open' button.
I'm closing this ticket, feel free to re-open if I've missed something.
comment:6 Changed 11 months ago by
It seems that this flew under the radar for the client:
Download (for some reason) ... closes the transfers window
Is that the expected behavior? I may want to download and open the downloads directory e.g. to decompress the file, click-drag-open/attach it to some program/webmail
comment:7 Changed 11 months ago by
Is that the expected behavior? I may want to download and open the downloads directory e.g. to decompress the file, click-drag-open/attach it to some program/webmail
Done in r25689.
comment:8 Changed 5 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2641
The manual page for
xdg-open
shows: xdg-open {file | URL}, xdg-open - opens a file or URL in the user's preferred application.So using multiple arguments is not meant to work. Don't do that.
If you allow remote-open, the request to open the file will be forwarded. See
open-files
andopen-url
options.Hmm. Don't all desktop environments have a shortcut for that already?