*** This bug has been marked as a duplicate of bug 696802 ***

Reopening because bug 696802 got hijacked for something else.

It seems that Tracker will index all supported file types in configured folders, so we can't ask Tracker to index ~/Download but leave out pictures from ~/Download.

We can add a preference dialog to customize which folders Photos will use. By default, this dialog will show all tracked folders, and two behaviors should be implemented:
1) add behavior: add this folder for Tracker to index
2) remove behavior: only Photos leave out this folder

I think 2) is easy to be implemented, but I have no idea on 1). What do you think?

See comment 0 in bug #696802 for my opinion about that. Personally, I rather NOT have a preferences dialog, I'd rather Photos would "Just Work" without fiddling with settings.

While we do acknowledge the original problem in the bug report, we are still undecided on the solution. One option is to have "import to photos" action in, say Web, which will add the item to the Tracker DB in a way that it will show up in the application. Maybe by copying it over to ~/Pictures. At that point we can stop looking at ~/Downloads.

Remember that the whole point of Documents, Photos and the other content applications is to let the user avoid dealing with files and directories.

If we suddenly stop showing ~/Downloads then the PDFs and images that you randomly downloaded from the Internet won't show up any more. The only way to make them show up would be for the user to manually copy them over to ~/Documents or ~/Pictures, at which point the whole point of the application is lost.

So, if you are interested in solving this issue, please discuss in #gnome-design and decide upon a high level design for this. Then we can see how we can arrive at the solution.

Also see https://bugzilla.gnome.org/show_bug.cgi?id=731652

*** Bug 748319 has been marked as a duplicate of this bug. ***

I have a suggestion concerning design:

Add option called "My Library" or simply "Library" on Photo's menu (the one on the GNOME Shell top bar).

After clicking, a dialog open: it has a brief explanation ("This are the directories that GNOME Photos will look for your photographs" or something like that), a list of directories (~/Photos and ~/Downloads by default) and +/- buttons (to add and remove directories from the list).

This way we both:
1) Maintain a sane default, that is reasonable enough to keep users from dealing with folders/files directly. 

2) Add a option to non-default users (who may keep photos on multiple folders, very likely on the ~/Documents folder, or simply don't want photos inside ~/Downloads showing up on the app). The configuration is as straightforward as possible, and simple enough to the average user to find and use. This also avoids a new "Preferences" menu.

For most people, the only folder that needs to be handled by a "photos" application is the one where all imported photos end up. This folder is (or should be) the XDG-defined pictures folder. So, by default, gnome-photos should only display pictures that are physically located in the Pictures folder.

Now, there should also be an option to add pictures from other folders, using at least one of the two following solutions:
 1) allow to import pictures, which would result in the copying of thos pictures to the Pictures folder.
 2) allow to add other folders in the white-list of tracked folders.

1) is a must-have while 2) would be nice.

By the way, I think it's also very important that gnome-photos and gnome-music behave in a same way. How is this problem currently handled in gnome-music?

(In reply to Julien Olivier from comment #9)
> For most people, the only folder that needs to be handled by a "photos"
> application is the one where all imported photos end up. This folder is (or
> should be) the XDG-defined pictures folder. So, by default, gnome-photos
> should only display pictures that are physically located in the Pictures
> folder.

Should it always be the entire XDG-defined pictures folder, though? I mean, yes, all photos are pictures, so that's certainly a better default than "everywhere in $HOME".

But not all pictures are photos, so it would be *very* nice if that assumption wasn't hardcoded in gnome-photos and if it were possible for a user to narrow down the search even further (e.g. to ~/Pictures/Photos, or even ~/Photos – removing ~/Pictures entirely).

at present gnome-photos import photos from all the directories. but if someone downloads some app,or saves a page from internet, it contains a lot of images which are surely unwanted. so we could just give user an option to discard some directories and gnome-photos will not import photos from those directories. we can't stop tracker from searching those directories but, if we could introduce a filter while loading photos into gnome-photos we could get ride of those.

Let me present my use case: my family has a shared folder (/home/shared) where we store our common things. Mainly photos, movies, and so on.

So when I open GNOME photos, it is full of the garbage I have in ~/Download, but has no photo from /home/shared/Photos. So, right now, it's useless to me.

I think a dialog for choosing which directories to track, with a sane default, is best choice. Something similar to what Déjà Dup has.

Same for videos, although that should be another issue.

Despite all its plus points, this one issue makes gnome-photos extremely hard to use. For instance, I have a folder full of images that I use for research work on image processing techniques. When I open Photos all these images are shows, and make the interface a cluttered mess.

Moreover, it may have helped if these image files were sorted into an album based on their source folder.

I hope the designers and the developers revisit this issue.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-photos/issues/9.