sorry, didn’t know that.
But it’s kind of inconsistent now that with Sailjail many other ‘built-in’ applications can’t access anything outside of folders in ~ dedicated to the corresponding file type. For example, it’s no longer possible to open in the Media player an .mp3 music file located directly in /home/defaultuser/, it has to be moved to ~/Music first. (of course, I could easily whitelist it in Sailjail config files, but I am talking about the standard situation).
I would very much like Gallery to be able to provide access to pictures outside of the ~/Pictures folder, but as a configurable option. In other words, ~/Pictures and ~/android_storage/Pictures by default (and of course the same for videos), and everything else optional, as a user configurable folder list.
No, in fact it is exactly the same with the other apps. All these apps have UserDirs permissions, i.e. all those standard directories - they are not limited to their respective primary directories.
Being more limited to the expected directories could be good, but i still think seeing Downloads and the SD card is very much how it should work.
However, Tracker is probably not very prepared to handle that different consumers of its information has different views of the filesystem.
If something as simple as this needs to be configurable, the implementation is very often wrong. Call me an Apple user, but there should be one good way to do it that is enough for everyone.
Well, I’d insist that there are still many inconsistencies. Like for example that while using the built-in web browser you are allowed to download a file to /home/defaultuser/ but then you cannot open it from there neither by tapping the notification about successful download nor via the browser’s Downloads menu option (which opens the “Transfers” page) as in both cases you get a “File not found” error message, even though the file is there. In order to be able to open a downloaded file using any of those methods you need to download it to ~/Downloads (or I guess the remaining subfolders too, just not directly to ~), from where opening it does work correctly from both the Transfers list and the browser’s “File successfully downloaded” notification.
Actually, maybe I should fill a bug report regarding it…
On a second thought, yes, you’re absolutely right. So maybe a configurable user’s blacklist instead…?
I’m fairly sure you can’t. It goes to that application’s view of ~, it does not actually end up there. By all means, bug-report the limited feedback on that (we are staring to get away from the topic).
Even worse for the user to have to faff with. Options are a bad, last-resort, option.
1 Like
sorry but if that’s the case, go use Apple OS. Many users are here because they don’t like “the apple way”. And I can argue with you as long as you want as there are multiple ways of doing something and all the solutions may be valid it’s just depends on the user which one he likes because many users use the phone in different ways. Same as with the hammer, that’s why we have multiple hammers with different heads and even these heads are different from both sides.
1 Like
Oh yes, you can 
Why don’t you just give it a try? 
First it shows a “Select location” dialog, where you can select between “Home directory” or numerical ID of your memory card (pretty incomprehensible for novice users). Selecting “Home directory” lists the contents of ~, where you can EITHER go deeper by selecting one of the subfolders OR just press the “Download to defaultuser” button which dowloads the file directly to ~. Which itself is fine, the only problem being that you then can’t access the file using any of the remaining options or from the notification because it gives you the misleading and untrue “File not found” error.
If I wanted a dumb, option-less device not giving me any choice but what someone else thought out would be the best for me, since 2007 I would have been an iPhone user.
I did try. It worked exactly as expected, the file not actually landing in ~ as viewed from anywhere else than the browser itself. Yes, including unjailed terminal, i.e. for real.
Unless you didn’t notice, the N9, and Sailfish are beautifully devoid of setting clutter. Just the way i like it.
Anyway, now i’m out of this thread (feel free to continue elsewhere) since we are now dangerously near off topic.
Well, indeed, you are right in that the file did not land in ~. Which doesn’t actually mean any good as it’s actually even worse. It does not land ANYWHERE as it’s simply nowhere to be found, despite the requester accepting /home/defaultuser/ as selection (and explicitly saying “Download to defaultuser”), notification about successful download being shown (that, when tapped, says “File not found” - which actually turns out to be true) and the Transfers page also listing a successful download (and again, only when tapped saying “File not found”). I actually suspect (judging by the time passing between pressing that “Download to defaultuser” button and the “File has been downloaded” notification) that the file actually does get downloaded to some web browser’s temporary folder, and then the browser fails to copy it to the selected destination (as it doesn’t have permission to store it in ~), which only wastes time and data traffic.
So in this shape it is a mess. Calling it inconsistent was actually an euphemism.
Please accept my right to respond. Now I’m done, too.
Hi @lolek. I had a look into this, but at the moment I’m either not experiencing the issue that you’re facing, or not fully understanding what the issue is.
Currently the Gallery defaults to showing four different image categories: Photos, Videos, Screenshots and Android storage.
The Photos category is configured to show images in user folders, excluding the Music folder, the Screenshots folder, or Android storage folder (or subfolders thereof). Anyone interested can check this by viewing the /usr/share/jolla-gallery/gallery.qml source code for the Gallery app, where we see the following:
filter: GalleryFilterIntersection {
GalleryStartsWithFilter { property: "filePath"; value: StandardPaths.music; negated: true }
GalleryStartsWithFilter { property: "filePath"; value: StandardPaths.pictures + "/Screenshots/"; negated: true }
GalleryStartsWithFilter { property: "filePath"; value: androidStorage.path; negated: true }
}
In the same file, you can also see that the Screenshots category will only show images in the ~/Pictures/Screenshots folder. There’s also something similar for Android storage.
So, I’d expect the Gallery app not to show images from your Music folders.
I tested this on my own device running 4.4.0.72 by moving an image between the ~/Pictures folder and the ~/Music folder. The image appeared/disappeared from the gallery app as expected.
So if I’m understanding your report correctly, and the Gallery is showing image stored in your Music folder, then this would seem to be a bug.
To get to the bottom of this, one thing to double check would be the actual location of the image files that you’re not expecting to see (the fan art images you mention).
Would you mind please viewing one of the files in the Gallery app and selecting the “i” icon (top left of the image) and checking the file path and copying out the result here please?
1 Like
the path is: /run/media/defaultuser/78B7…/Music/Artists/Album…
so it seems the problems are files located on the microSD.
Thanks for checking. That makes more sense then as files on external storage are intentionally included. It’s not really reasonable to assume any particular structure for the folders on SD cards, say.
Do you have the SD card permanently mounted? If so, you could consider adding an exception to the /usr/share/jolla-gallery/gallery.qml file for the Music folder there, but it would be specific to your system and SD card.
well the solution would be easy. Settings for gallery where user could manually add folders which he’d like to exclude.
For the sdcard I think that the same patterns could be applied than they are right now for the builtin memory and of course this could be possible to disable using… gallery settings.
Unfortunately the SD card use case doesn’t sound so simple to me, given we can’t assume there’s a particular folder structure on the SD card.
I can see that adding the option to exclude particular folders would work better for you, but this would definitely require additional design and implementation work. I’m not saying it’s a bad idea, but it’s not going to be an immediate fix for you I’m afraid.
I originally started looking at this because you raised it as a topic for the community meeting on Thursday. Are you still interested in it being discussed there?
well it’s simple…
SFOS expects the following directories in the /home/defaultuser:
Music, Documents, Pictures etc
so if sdcard has Music folder in the root dir then assume it’s the same as in /home/defaultuser but as I said, make it a config variable.
well it can be done right now adding config page to the gallery settings
well I asked a question:
Since the request is right now 10 years old! I’m allowing myself again to ask for the date, when we can expect this to be fixed/implement?
and I’d like to get the answer. A lot of people commented and it seems a lot of people asked for this. It would be nice to either say - “we will do this for the next release” or “nope we don’t care”.
Also, I could try to add that gallery settings on my own but I’m not sure how to handle this. I was looking at sailfish-weather settings. There’s that file: /usr/share/jolla-settings/pages/sailfish-weather/SettingsPage.qml I’m missing similar file for gallery. Well it’s obvious since gallery has no config.
If someone could help me with this I think that maybe I could try to look at it the same way I handled the address bar today.
Understood; I will keep it on the agenda then.
If I’m right, you can add a file called .nomedia in the directories where it shouldn’t be listed in the Gallery.
this is not an option. Cause then my music won’t be indexed.
AFAIK, we have .nomedia, .trackerignore and .backup-metadata (https://forum.sailfishos.org/t/newly-created-images-displayed-twice-in-the-gallery/9357)
They seem to be synonyms to exclude a dir from tracker indexing.
The simplest to implement, as starting point, would perhaps be having files like .nopicture, .nomusic, .novideo....
We could place those files to selectively exclude directories from indexig.
1 Like
Tracker is not owned by Jolla, what’s worse it’s part of Gnome means almost impossible to do anything there.