pooh The non-minified javascripts are also downloadable from cdn.jsdelivr.net, just get rid of the .min bit of the URL. Except for your own files.js of course :-)
Yes, our files.js
is already minified, regardless of using .min.js
in the url or not. You can "beautify" a minified JS to make it slightly more readable, but it will still have meaningless variable names and no comments. Even if you had access to the source, it would be scattered across several dozen Javascript files, and was never created to be public and easy to edit, even for other seasoned developers. There are also other reasons why we don't wish to share the Javascript source code.
The aim is to offer a public API so that you can change critical features or add custom items. In fact, you can already add your own context menu buttons from custom.js
. See docs and check contextmenu
... You could use that to create your own "share" button, although you would not be able to use the apple-share-icon, because that's not included in Files.
https://www.files.gallery/docs/javascript-config/
pooh By the way, am I right to assume that you use AleeeKoi's js-file-downloader to download single files?
Actually no. Single file downloads don't use Javascript, because best functionality is already provided with "download" attribute in <a>
links. It will simply download the file, starting immediately, showing native browser progress, downloading to default device folder. I think the only case where native browser-download is not most optimal, is when using as PWA as in your case.
/AleeeKoi/js-file-downloader/ is only used for two features, both disabled by default:
- When download_dir is set to
files
in which case browser will download multiple files directly without zipping first (only works in desktop browsers).
- When download_dir is set to
zip
(on server), in which case we need to use some progress to detect when the download starts, because processing the ZIP on server could take a long time.
pooh Could that be a difference between 0.5.0 and 0.6.0? Indeed the download folder option is now available on my iPhone. I had set download_dir' to 'files' under 0.5.0 (now set to the default "browser' under 0.6.0).
Yes. As noted above, files
only works for desktop. I even tried loads of workarounds before releasing 0.6.0
, but files
option simply does not work properly in mobile browsers. New browser
option works nicely, although it zips the downloaded files.
pooh One of the things people might want to do is add a picture from files.gallery to their own iOS Photos library. Cumbersome on iOS when you press download. One option is to "open in new tab" and use the contextual menu then to download a picture to ones library. I realise by the way that files is meant for much more than just pictures.
I think the solution here is to add the Web_Share_API for supported devices, as it's a huge advantage on mobile devices. I will need to study it and implement it properly, with fallbacks.
Apart from when using the Web_Share_API, the limitations you mention apply for all web photo galleries of course. Unless a photo is accessed directly by URL in browser, you can't offer other options than "download", with links pointing to the raw image url. An alternative is long-tap on a loaded image in the popup, but this is currently blocked in Files due to some swipe gesture functionality.
pooh So it might be useful under Safari on iOS as well.
You have convinced me that the Web_Share_API would be tremendously useful on mobile. I will look into it soon, if not for next release. We might need some options ... For instance, when "sharing an image", many owners want the link itself to be shared and not the image ... This would be normal behavior when traditionally sharing across apps like "Line", "Facebook" or "Messenger" when the owner wants to keep the visitor on the website. Unfortunately, we can't have a single button that shares two different links ... It's either the raw image url, or the URL (current url in browser).
For instance, if you are currently viewing an image in the popup, you will see Safari's existing "share" button (part of the browser). This will of course share the current popup URL, but some would wonder why the same icon within the Files interface would act differently? A bit of a logical dilemma actually ...