xdg-open bugs / improvements

[stdedos]

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

[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.

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?

[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

[Antoine Martin]

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.

[stdedos]

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.

[Antoine Martin]

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.

[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

[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.