Using Sailfish Pickers API for saving files

[flypig]

Continuing the discussion from Sailfish Community News, 30th June, Microtube:

@wetab73 asked how Sailfish apps are supposed to use the Sailfish Pickers API to export files from an app.

@unmaintained

@flypig

@wetab73

no way to enter a file name for saving a new file,

Are you referring to the MultiFilePickerDialog here? This component isn’t really intended as a way to save out files, but maybe I’m misunderstanding?

Then which one is intended for this purpose?

Do you have a specific use-case in mind? I don’t think there’s a general “save any file anywhere” dialogue.

The argument, from what I understand, is that Mobile apps are ideally expected to handle the file structure internally and not expose it to the user. See for example the Audio Recorder for one way that this is done.

The closest I can think of in use by the OS is saving out files downloaded by the browser, which uses the FolderPickerPage component (in this case the filename is predetermined).

If there is a specific use-case you have in mind, I’d be interesting to explore further.

[unmaintained]

@flypig

Do you have a specific use-case in mind? I don’t think there’s a general “save any file anywhere” dialogue.

Thank you, means I did not miss anything and don’t have to look any further.

I know the arguments why some people want mobile Linux devices to be cumbersome and awkward to use (e.g. by forcing developers to invent convoluted ways to achieve what would otherwise be a simple file saving operation), I just wanted to know if SFOS has also fallen into this trap

[attah]

But could you please provide just one example of when it makes sense?
(So this conversation might actually lead somewhere…)

[nephros]

@flypig

The argument, from what I understand, is that Mobile apps are ideally expected to handle the file structure internally and not expose it to the user. See for example the Audio Recorder for one way that this is done.

This is fine for files which have a specific application (or several) which can handle them. Files which need an application ro “render” them in a way the user expects. I.e. like media, and office-type files/documents.
A point can be made here that the file location does not matter as being able to open the file itself is of little use.

It is however not at all the same for more generic file types, such as plain ascii files, be they application config files, JSON or XML data.
In general, it can not be determined which kind of application should be able to consume them, only the user can tell. Therefore the application must enable the user to navigate to that specific location in order to open their files.

It follows that for the user to know where to navigate, they must be able to save into a specific path when creating, downloading or otherwise receiving the file.

You ask for a use case, how about this:

@User story

I as a support engineer for $COMPANY’s networking application, receice a customer’s request (per email which I read in Jolla Mail) to provide them with a custom configuration for their installation.

These configurations are generated at an internal web site, which I log into using Sailfish Browser, enter some customer-specific data and receive their config as an XML file customer.xml, which the Browser downloads (to a more or less unspecified, but at least configurable location).
As I do this regularly, I have several of these customer.xml files under ~/Downloads already, see below.
(Also, I’m in luck that our intranet site is badly wrtten and sends the file as application/octet-stream and not text/xml, otherwise the Browser would not have downloaded it.)

After failing to review the file briefly using Sailfish Office (which I can’t as it doesn’t list xml files in the Documents app), I use the secret file manager from Settings to go to the file location, selecting the right file from settings.xml, settings (1).xml, settings (2).xml, settings (3).xml,settings (2)_bak.xml etc, more or less by trial and error.
The file opens in Sailfish Browser (which is obvioulsy the correct application for anything that’s xml, but hey, the viewer is actually not half bad!). I can save the rendered XML view as PDF, but I can not otherwise save the already opened file.

Anyway, the contents look good, lets email it to the customer.

I open Jolla Mail, look for the request, hit reply (which causes the previous HTML mail to be rendered plain text and quoted, but okay), and hit the attach button. After finding out that neither Documents nor Downloads list my xml file, I must resort to (thank got it’s there!) File System section in the Picker, and voila! I can attach my file.

It would have looked much more professional had I been able to rename it from customer (4).xml to something else, but it’ll have to do.
I know all my customer read documentation, which states that is can only be named customer.xml, any other names will cause our application to not work. I’m sure they’ll be fine.

Exercises for the Solution Designer:

1. identify where in these actions an option to specify a file name and definitive file path would have enhanced the user experience
2. identify where in these actions the lack of such an option has degraded the user experiece.

Thanks for reading, and stay tuned for part 2, in which the customer tries to upload the received XML file to a SharePoint WebDAV location using their SailfishOs device.

[flypig]

@nephros

It follows that for the user to know where to navigate, they must be able to save into a specific path when creating, downloading or otherwise receiving the file.

As I understand it, only the creating step is in question here. The downloading and receiving cases are covered by FolderPickerPage, and the opening case by one of the of the others (e.g. FilePickerPage, VideoPickerPage etc. depending on what’s to be opened).

@User story

I as a support engineer…

Nice story, and definitely helpful. And yes, I can see that specifying the filename for saving the downloaded XML would be helpful here.

Even without this, I think the process can be streamlined. You could set the browser to ask where to store files (Browser > Menu > Settings > Save destination > Always ask) which will allow you to specify a definitive file path.

You can rename your files using the File manager (press and hold on the file > Rename), to — if I’m understanding right — make things look more professional.

Adding a shortcut to the File manager using devel-su pkcon install sailfish-filemanager might also make things a little easier.

Looking at it as a whole, my feeling is that ideally the flow wouldn’t involve having to deal with the file system at all: it should be possible to send the file directly from the browser to email using the Share API. Unfortunately this option isn’t available at the moment (you can share links this way, but not downloaded files).

[wetab73]

@attah

But could you please provide just one example of when it makes sense?

The aforementioned by others creation of a new file of any kind (which I wouldn’t consider a rare and exotic use). E.g. a new document or text note. Sure, it can just get some predefined name like “Text_Note_2022-07-04.txt”, but in most cases the user will then need to instantly go and manually change it in some file manager to something meaningful, or else in a few days he won’t remember which note is which.

But also downloading of files, as they often have names that one would like to change to something more meaningful. Why not allow to change the name upon downloading, rather than having to do it manually and requiring a file manager for that?

@flypig

Even without this, I think the process can be streamlined. You could set the browser to ask where to store files (Browser > Menu > Settings > Save destination > Always ask) which will allow you to specify a definitive file path.

What if it is about downloading a file via application, not the browser?

The application I am currently working on downloads an audio file, but not directly to disk but to a memory buffer (as QByteArray), from where the user can instantly preview (pre-listen? ) it, decide if he wants it or not (and make some modifications) and only then save it. Again, no possibility to let him choose the name, whereas those files by default often have pretty meaningless names.

As I said, it is not that I am trying to invent something exotic. File saving mode (where the pickers ask for file name) have been present on other platforms. For example, on BlackBerry 10, file pickers had a “mode” property of which one of the options was FilePickerMode.Saver or FilePickerMode.SaverMultiple. In such case, it was asking for file names (including the possibility to display some predefined name and letting the user modify or accept it). So, SFOS file pickers are definitely a STEP BACKWARD in this regard.

[attah]

@wetab73

The aforementioned by others creation of a new file of any kind (which I wouldn’t consider a rare and exotic use). E.g. a new document or text note. Sure, it can just get some predefined name like “Text_Note_2022-07-04.txt”, but in most cases the user will then need to instantly go and manually change it in some file manager to something meaningful, or else in a few days he won’t remember which note is which.

Or like in the notes app; there are no files (iffy) - and they are all displayed in a superior manner with previews.

In principle i agree with you, but in practice i have never missed it.

[wetab73]

@attah

In principle i agree with you, but in practice i have never missed it.

Well, as in the discussion about paid apps. IMO having more possibilities is better than having less. So I guess that it certainly wouldn’t hurt if (like on BB10 and earlier also on Harmattan or Symbian) there was either a ‘Saver’ mode of pickers or at least a property to optionally enable entering/changing file name to be saved.

I know one can do it individually, but (as everyone would do it differently) it ruins one of the fundamental rules of having an UX: consistent, uniform user experience, i.e. the same things and actions always looking and working the same.

And no possibility for the user to freely name a file he’s saving is simply… bizarre.

[nephros]

While it doesn’t solve the Pickers thing, I think having a Rename (or even copy/move) option in Transfers, and the Documents file list would go a long way without disturbing the “filesystem-less” concept too much.

[vlagged]

@flypig

Adding a shortcut to the File manager using devel-su pkcon install sailfish-filemanager might also make things a little easier.

That’s some neat info but then that’s not working today (blank “Files” title) possibly because of sailjail.

[wetab73]

@nephros

without disturbing the “filesystem-less” concept too much.

That allegedly “filesystem-less” approach of current pickers actually isn’t filesystem-less at all. Just take a look at those pickers, especially those multi-selection ones. They actually take you on a journey through the entire file system of your device. The journey starts from selecting a “drive” (Home folder, System files, Memory card), then the user travels between folders to find the desired one in which he then selects some files. But that’s just the beginning of the trip, as then he needs to keep pressing the “Accept (number of files) button” which takes him back level by level (one level per each button press) from the folder in which he made his first file selection up to the top, so that - as flypig explained - he can add files from other folders to the selection. The fun only ends when we’re back at the “drive” selection level (i.e. at the top of the file system) as only then that picker eventually accepts the selection and closes.

Is this really a “filesystem-less” approach, or maybe rather vice versa? And if so, then how an option to allow entering or modifying file names by the user in save mode could further spoil it?

Sorry, maybe I’m too used to BB10, which I considered the best mobile operating system ever created. But after its demise I came to SFOS just because I thought that its goal is NOT to be dumb like iOS or Android. With Maemo / Hildon as its roots, I don’t think this OS should become yet another iOS knowing better than the user how his files should be named or forbidding him to navigate to other folder than the one the app suggested.

But maybe I’m wrong.

[nephros]

You’re right, but I meant tackling the issue of file naming only, not the pickers as such.

If those two file listings had the option of file naming, it would be an improvement that wouldn’t disturb the design idea/guideline of ‘mobile users needn’t care about file locations’.

It’s even unrelated to any Silica components.

I realize that’s a tangent the main topic of pickers, but I think it would improve things in the context of some use case(s) which call for a ‘save file as’ dialog. I.e. Files created by browser, Bluetooth, and email download events.

Iff apps could ‘register’ their ‘save’ actions with ‘Transfers’ then, they could save with a generic file name first, and let users optionally rename later in that view.
Thus could potentially even be more elegant than a new proper ‘save to location and enter file name’ picker dialog.

That all being said, I agree that the whole picker plugin is in need of a revisit and update.

[poetaster]

I have a need for choosing a location in the case of Stopmotion. Since it produces series of images, just ‘dumping them’ in Pictures in not really an option.

At present I use a picker to choose either a Folderpicker local or /run/media. It would be really nice to be able to create a sub-directory. Currently, I’m using a text input and integer increments.

In the long run, for my use case, just picking the base folder is sufficient, but not ideal since it requires multiple steps (1. choose base folder, 2. enter text for base name) in different locations. But I’m also still prototyping so maybe I’ll come up with something clever and re-usable.

[flypig]

@vlagged

(blank “Files” title)

I’m not exactly sure what you’re seeing, but I tested on an Xperia 10 and it works for me running a standard Vanha Rauma install.

[dcaliste]

I think having a Rename (or even copy/move) option in Transfers, and the Documents file list

Yes, I was hoping to implement this rename action in the document application for a long time, but I didn’t actually take the time to do it yet. I fully agree that the name itself is more important than the place (in that case). I can still tap on the info to get the full path when I need to navigate to it for whatever action (scp or something else).

[vlagged]

I only have this, but it might be other bug than sailjail usage, as it shows the same when started from terminal

[flypig]

That does look strange: you should have a list of storage devices there. What’s your device and the version of your OS?

[vlagged]

Thank you for the quick response,
https://build.sailfishos.org/project/show/nemo:devel:hw:xiaomi:tucana
4.4.0.58

[nephros]

Looking at the qml, it looks a bit as if the deviceStorageModel (and externalStorageModel) are empty. That should give such an empty page.