Xpra: Ticket #2641: xdg-open bugs / improvements

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:



Fri, 13 Mar 2020 09:40:57 GMT - Antoine Martin: owner changed

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.

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 and open-url options.

Add an Open Download Directory

Hmm. Don't all desktop environments have a shortcut for that already?


Fri, 13 Mar 2020 12:36:02 GMT - stdedos:

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 and open-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


Sat, 14 Mar 2020 16:31:04 GMT - Antoine Martin:

Updates:

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.


Sat, 14 Mar 2020 17:56:02 GMT - stdedos:

Replying to Antoine Martin:

Updates:

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?

In my eyes, you did this ^^^ in the previous commit; here you removed the now-unneeded loop :/

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.


Sun, 15 Mar 2020 02:48:23 GMT - Antoine Martin: status changed; resolution set

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.


Thu, 19 Mar 2020 15:19:26 GMT - stdedos:

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


Thu, 19 Mar 2020 15:32:34 GMT - Antoine Martin:

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.


Sat, 23 Jan 2021 05:56:49 GMT - migration script:

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