Add an option to overwrite downloaded files instead of creating unique copies

[cjohnsto-nz]

Basically, I would propose a change allows the user to select whether to download files with unique filenames, or simply overwrite.
I don't see a value in creating new file names honestly. If the user is accessing files from Kiwix, then it will create and open the file they click on even if, for example, every PDF in the ZIM has the same name, which is impossible anyway.

Alternatively, we could just change the code to ReplaceExisting as below.

[Jaifroid]

@cjohnsto-nz Thanks for the suggestion and suggesting which code could be changed. Ideally I think we'd want the sytem (or the method) to detect if the file exists and ask the user whether they wish to overwrite. Originally I had intended each file to have the filename it has in the ZIM -- for example if someone is downloading an EPUB from a Gutenberg ZIM -- but this has been buggy, so it would be worth looking at the code again.

Do you think a FileSave picker could be a good solution? At the moment, in the UWP app a downloaded file opens immediately after the user requests it, with no choice of where it's saved. In the PWA version (https://pwa.kiwix.org) the browser can offer a file picker depending on how the user has set up download options (this is browser code, not coded specifically in the app).

[cjohnsto-nz]

From my perspective, the most ideal outcome would be to open the files in the intended application with no addition input from the user required (after tap/click). In a situation where all filenames were unique (per ZIM), it would be best to check if the original file exists, and overwrite it if it has been updated (more recent ZIM, same file name). Otherwise, open the existing file to save IO.

I think it's also important to have behavioral parity between different Kiwix platforms. I understand that other platforms, such as the browser extensions, have limited access to the filesystem; can't compare sums, delete files, etc.

I think the best option would be to have an option available to Overwrite, or to Prompt, with the default set to overwrite. I think this would cover the vast majority of use cases, and improve the user experience.

You mention some bugginess with EPUBs and the Gutenberg ZIM. I'm curious what that use case involves. Do they have duplicate filenames? Or is it more a matter of making sure files with the same name that might be newer on the ZIM than existing in the filesystem are opened?

[Jaifroid]

You mention some bugginess with EPUBs and the Gutenberg ZIM. I'm curious what that use case involves. Do they have duplicate filenames? Or is it more a matter of making sure files with the same name that might be newer on the ZIM than existing in the filesystem are opened?

I'm just thinking of the difference between the UWP download method and the HTML/PWA download method. In the latter it's not possible to set the filename (without using the File System Access API). The UWP API seems to add some random digits on the folder name -- I need to check if they remain the same across sessions.

It's not really possible to make a uniform experience across the different variants (UWP, PWA, plain HTML5), because each API works a bit differently and has different capabilities. But we could get more uniformity between UWP and PWA.

Noted about an option for overwrite vs prompt -- if it's technically possible. I need to investigate.

[Jaifroid]

PS The use case for downloading EPUBs is that they are no longer supported in browsers directly, so you need an external application (or possibly a browser extension), or you may want to transfer it to an e-reader. It's clearly much more ideal with an EPUB if its filename is the title of the book. People often want to save the EPUB in a collection of Books / PDFs on their filesystem, and there is more of a case for wanting to come back to the file (not re-download it) because reading a book may take several days.

[cjohnsto-nz]

The UWP API seems to add some random digits on the folder name -- I need to check if they remain the same across sessions.

I just tested it and it does. It even seems to stay the same between refreshes of the ZIM file. I've recompiled the ZIM a few times, and it's still downloading to the same directory. It looks like the string is tied to the app install or product ID more than anything else.

It's not really possible to make a uniform experience across the different variants (UWP, PWA, plain HTML5), because each API works a bit differently and has different capabilities. But we could get more uniformity between UWP and PWA.

I certainly empathize with that. I accept that there will always be differences in the way that the different platforms behave, but I feel like opening a PDF in the default app, or in browser, without creating duplicate copies must be possible on all platforms.

[cjohnsto-nz]

PS The use case for downloading EPUBs is that they are no longer supported in browsers directly, so you need an external application (or possibly a browser extension), or you may want to transfer it to an e-reader. It's clearly much more ideal with an EPUB if its filename is the title of the book. People often want to save the EPUB in a collection of Books / PDFs on their filesystem, and there is more of a case for wanting to come back to the file (not re-download it) because reading a book may take several days.

Gotcha. It definitely seems like my use case overlaps the EPUB users in a lot of ways. That said, I think my preference would to Overwrite without prompt, while theirs would be to Open Existing without prompt. The files I'm working with are much more likely to be updated, but have the same filename, than an EPUB would be.

[Jaifroid]

OK, thanks for checking. It's certainly possible to alter that behaviour relatively simply here (at least in the UWP app).

I've just checked the NWJS and Electron versions of this app (https://kiwix.github.io/kiwix-js-windows/kiwix-js-electron.html), and they both invoke a filepicker when you download an EPUB. I know it's not quite what you want, but that behaviour could prevent creating multiple duplicates until we come up with a more generic solution. Just note that those versions don't self-update.

[cjohnsto-nz]

That version actually works perfectly for my use case. It opens the PDF in an external window without asking, and it remembers the last opened ZIM. Thank you so much,

Is this version planned for LTS?

[Jaifroid]

Is this version planned for LTS?

Is it the Electron or the NWJS version you refer to? By LTS, do you mean "will I continue to support these versions long term?" I don't have plans to deprecate either, but if the PWA version gets equivalent APIs once installed (it's getting there, but not yet), it may make Electron/NWJS a bit redundant. Why use a large Chromium framework if an installed Chromium PWA does the same thing as well in a much more lightweight way? The main reason to keep these is compatibility (believe it or not, we still have some Windows XP users out there for whom NWJS is their only option now!).

By the way, in Windows 10/11, it is now possible to install and update the Electron version just by typing winget install kiwix-electron in a command prompt / PowerShell. Or winget show kiwix-electron to give details of the current latest package.