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.
