Indeed.
And i was not arguing against paid apps (i’m all for it!), i was adding arguments against that it would somehow “solve the app situation” on the wider scale. Only so many use-case can be handled by indie developers. That is not the same as that wouldn’t benefit from it at all.
too bad i guess, not my fault
You can download it directly with Browser: Microtube | OpenRepos.net — Community Repository System
As you are on X10III, you need the aarch64 variant of the newest version (at the bottom of the list).
1 Like
I don’t think it would solve the situation, either. Because it is very late (too late?) and some serious opportunities had already been wasted (2013-2014 when Symbian Qt developers were looking for a new platform for them, and then on a much smaller scale 2018-2020 when BB10 developers were doing the same). Sadly, Jolla didn’t even turn head in that direction.
Anyway, while it surely wouldn’t solve the situation, it might at least more or less improve it.
So, I would really love to hear from Jolla what are the TRUE reasons of their so apparent reluctance to start supporting paid apps. They’ve got a well working payment processing system in their shop, so it’s not that. They’ve got a very strict application verification in their store, so it’s not the risk that they might be selling something harmful. So, is the whole problem really just about not willing to spend some euros on commercial Qt licencing?
Holy ****, indeed! I’ve had to add a counter to onAccepted to only react to the second signal. Let me guess, for how long it’s been broken like that? Years?
Is there a bug report related to this? I couldn’t find one. If no, could you or @Mister_Magister create one?
It’s not my problem to fix jolla’s broken software when they don’t even bother to test their stuff.
Well, it takes creating a bunch of bug reports regarding file pickers:
- this aforementioned double onAccepted
- Accept button in multi picker instead of just accepting the selection takes up one level in the folder structure, it takes pressing it multiple times (depending on how deep you start) until you reach the top of the file system, only then it accepts selection and closes the picker
- if you feed a file picker dialog with default path, there’s absolutely no way to change the folder by the user
- no way to enter a file name for saving a new file,
- and probably more.
I think it would really help if you could create those bug reports.
I know it takes time and you might be frustrated because you think that should already be fixed,
but it would improve the situation. (Also it is quite satisfying to see issues fixed because you reported them)
1 Like
Look at the huge mountain of care i don’t give, oh boy you can barely climb it
Jolla caused me enough pain that they can fix their own bs
Thanks for highlighting this, which I agree shouldn’t be happening. I’ve created an internal ticket about it, but also proposed a pull request to fix it. If the PR gets accepted (it’ll need to go through review first), the fix will then make it into a future release.
This is by design, to allow the user to select more files. There is a way to avoid this (you can check the browser source code to find out how), but as part of the PR I mentioned earlier I’ve also proposed a property to make this more easily configurable.
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?
If there are more, please do file bug reports as @thigg suggested, or propose feature requests. The nature of APIs is that it’s very difficult to know how developers will want to use them in advance, so input into the process is always appreciated.
3 Likes
Then which one is intended for this purpose?
FilePickerPage seems to be only meant for picking an already existing file.
1 Like
This feels like a topic in its own right, so I created a separate thread:
3 Likes
I do create bug reports. There have been multiple reports created by me in the past months, including some that already got fixed thanks to it. Also this time, I do intend to create all the needed bug reports, but first I wanted to test it a little bit more (and discuss it with others) as I’ve only discovered those problems in the past few days. I think that there’s no rush, it can wait one day or two.
It’s a great news!
Oh, so it is about allowing selection of files from multiple folders, right? Nice, but quite an above-standard and rarely used feature, I think. I guess that in most cases people select multiple files from one folder. And in such case it is extremely confusing that you press “Accept (number of files)” and it does not accept anything but goes one folder higher, then again one folder higher rather than accepting, and so on until it reaches the top. If we start in something like e.g. “~/Documents/Work/Some_project/Recent” it takes pressing that “Accept” button FIVE TIMES in a row to be able to eventually exit the picker and have the selection accepted… Which is… cumbersome? annoying? completely misleading?
So maybe such an advanced and rarely used functionality should be made optional, e.g. through setting some extra property of the picker, e.g. “multifolder: true”. Or maybe all the pickers should use the common way of going between folders in file selectors, i.e. the “…” or “Parent folder” link shown on top of the file/folder list.
Actually, unless it’s just my inability to find it, none of the pickers allows entering file name. So does it mean that none of them is intended to save files? Which I guess is a pretty common functionality.
There are pretty COMMON uses of file pickers, which are supported by default on other platforms. E.g. the aforementioned file saving, which obviously requires selecting a destination folder but also giving the file a name. On virtually all other platforms pickers have a save mode where they ask the user for file name.
And the same applies to
It is very common to open a picker in some specific location, e.g. the folder the user had chosen the previous time. That’s what my application does, too: it remembers the folder that was selected by the user previously and the next time it opens the picker there for user’s convenience, as - quite likely - he will be opening files from the same folder. But if not, then there’s ABSOLUTELY NO WAY for the user to go to any other folder, as file pickers in their current form don’t provide any possibility to change a folder in such case.
As I wrote, it could be easily solved by always displaying a “Parent folder” or similar link on top of the file/folder list in pickers, like it is so common in file/folder browsers.
I would expect “accept” to actually return me to the appkication directly and, if I wanted to attach/select files from different paths, I would have to enter the multi picker again.
Adding files from different paths in the same instance of multipicker is not something I recognize from other OSes/applications, but I may be mistaken (and I only have access to my sailfish device right now).
2 Likes
So do I. The button says “Accept” so I’d expect that pressing it accepts the selection and closes the picker. I was very confused when pressing it took me to a parent folder rather than accepting anything. And then the same happened on each following press, until it reached the top of the file system. At some point I even thought that it got stuck or something.
There should be a separate item/button to go between folders, while the Accept button should be used for the final confirmation and closing the picker. Or else it is confusing, quite cumbersome and time consuming if one only needs to select files from within a single folder (which I think is the most frequent use) but the picker takes him through the entire filesystem and requires pressing the button repeatedly so many times.
I have a suggestion to improve the dialog “obviousness”: have the dialog say “x files selected in y folders” so the behavior gets “justified” by the status line.
I don’t remember ever seeing a multi-folder multi-file picker in any operating system before, but I think this feature is cool and worth having/keeping! I can see use for this in, for example, selecting documents and pictures to attach to an email, or attaching a picture and a screenshot to an email.
Just my 2 cents 
Sure multifolder selection is worth keeping for certain uses, but why not make it optional through a property, like eg. multifolder: true/false. This would allow developers disable it where it certainly wouldn’t be needed and would only be confusing.
2 Likes
Yes, I can agree on the usefulness of this picker, but it needs some UX work to be useful. What is the flow for a user utilizing this picker? How does the UI present the state and possible actions? Are the “hints” obvious or depending on the user’s knowledge of the actual implementation?
In the current state I don’t think it’s usable.
This topic was automatically closed after 30 days. New replies are no longer allowed.