Fetch and set default file name + extension automatically about transfer HOT 9 OPEN

@TtuxX I've fixed the focus; it was focusing on the file name box because I added autofocus to both inputs by mistake.

I'll look into your other suggestion soon. (Opened #7 for that.)

from transfer.

+1 for the file extensions

from transfer.

I will look into better handling of file extensions this weekend.

There are three cases that we need to support:

• File extension within the original URL, which can simply be extracted by text manipulation.
• File extension within a redirect, which can be extracted by a similar method, but not until the request has been sent.
• File extension not in any URL, in which case it must be guessed based upon the MIME type given by the remote server.

We also need to be careful not to split out bogus extensions from links which just happen to contain a dot.

I would like to present the dialog as follows:

In the second two cases, the extension can't be known until the transfer has started (unless a user inputs it manually). How would be best to present the idea that "file extension is unknown, but will be determined during download"? Just a line of text underneath the input?

We could also try sending a HEAD request from the client side to get some metadata from the remote server without actually downloading the file. This includes the MIME type, which would allow the extension to be guessed and displayed in all cases. However, a large group of websites don't support HEAD requests, so this won't always work, and we can't send a GET request because that would start downloading the file to the client.

from transfer.

Hello! 👋

As of v0.2.0 which I released a few hours ago, the file name will default to the remote name if you leave the text box blank.

As for defaulting the file extension, I could split the file name input so that a new name can be entered while automatically keeping the original extension?

from transfer.

That would be nice! :)

Do you think also it could be possible to focus first on the download link input field instead of the file name ?
And support catching the "ENTER" key to start the download directly ? :)

Regarding the pop-up that lets the user know that download has started, could it be possible to replace it with a notification like the Analytics app's, on the top right corner ?

Current pop-up requires a user interaction:

Non-obstructive Analytics app's notification on top right corner:

from transfer.

Hello! wave

As of v0.2.0 which I released a few hours ago, the file name will default to the remote name if you leave the text box blank.

As for defaulting the file extension, I could split the file name input so that a new name can be entered while automatically keeping the original extension?

Hi danth ! Thank you very much for these changes !
As regards to files extensions I still have an issue where the extension is missing if I download an image without the extension at the end of the URL.
As mentioned in #4 (comment), would it be possible to fetch the file MineType before the download, and then set it automatically ? :)

For example if I try to download my Github avatar (https://avatars.githubusercontent.com/u/6570830?s=80&v=4), the downloaded file won't open as the extension is not fetched and included automatically.

from transfer.

The line of text and HEAD request both seems to be a great idea!

I wonder in absolute in which cases the user should specify manualy the file extension.
Maybe we can fetch it and, if not possible, we download the file anyway (as this is in the end what the user wants), then set the extension afterwards, right before displaying it in the NC files ?

I wonder if there are specific cases where the user would better know the filetype than the machine. Also if the user sets the wrong extension, the file might not be usable from within NC.

All in all there might be consequences I don't fully understand but I think the extension field could maybe even be removed, thus further simplifying the interface in the process of making it straightforward and as automatic as possible for the end-user ? :)

from transfer.

I wonder if there are specific cases where the user would better know the filetype than the machine.

In the following GitHub link:
https://github.com/danth/transfer/blob/master/lib/Service/TransferService.php
the file extension is php however when downloaded this is actually a html page.

Perhaps we should mitigate this by always using the content type reported in the headers rather than guessing based on the URL.

I think the extension field could maybe even be removed

If we always use the reported content type, then there will be no cases where we know the extension before starting the job. In that case I think the best option would be to remove the input box completely. The file extension can always be changed afterwards by renaming, in the rare case that the mime type is reported incorrectly by the remote. However if there is no extension field, it should be made clear that the user does not need to type one.

On the other hand, there are some file types for which there is a choice between extensions. For example, jpg and jpeg both represent the same image format. A user might want to set this before queuing the job so that they don't need to come back and rename afterwards.

from transfer.

I fully agree for the content type! Regarding your specific link however, your program appears to work correctly as if the user wants the php file, he should in first place download the URL linked the Github Raw button :)

Regarding the choice between extensions jpg and jpeg (I'm speaking for myself) but if the extension is correctly detected in the first place it will not really matter to me about jpg or jpeg as long as Nextcloud recognise it.

Making the app as simple and straightforward as possible could be nice as I used to love the download feature back when it was included inside ownCloud's core in 2015 ! :)

(more details in owncloud/core#13326)

from transfer.