Open elementaryBot opened 7 years ago
How can this have low priority? I'm having daily having a hard time with this, in OS X it's very easy to go through images on disk, in the order used in the Finder, and delete for example the blurry ones. This is very painful with Photos, it takes a while before it enables going to a next and previous photo, it has it's own sorting and you can't delete photos. Is there another workflow I'm not aware of?
Launchpad Details: #LPC Peter Uithoven - 2016-05-28 17:45:50 +0000
This is the single biggest issue that has been tormenting me ever since I switched to Linux years ago. I download a lot of images and often feel the need to view a batch in the order they were downloaded. It was simple in Windows - just sort the folder contents by date and the default image viewer uses that order. It's bizarre that none of the several Linux distros I've tried behave in this expected manner, even after years of bug reports. The technical argument I've come across is that the image viewer can't access the settings of the file manager. I thought elementary, with its own apps, could overcome this. Sad to see such a serious usability issue marked as low priority :(
@jversusk but I think it should be possible to sort the pictures inside the app... (it's not implemented yet)
@artemanufrij Seems you're missing the point. The idea is for the image viewer to automatically use the file manager's sort order for different folders, without the user having to change the setting again and again.
PS: One potential solution might be to make an image viewer extension for the file manager, kinda like sushi/gloobus but limited to images. Wouldn't such an extension be able to access the file manager's settings?
I understood your point. but I guess it's currently not possible to relate the sort order from files to photos. so my suggestion was to implement sorting into photos directly.
I believe this report is about the image viewer, not the full library. I guess Files should probably save its sort order preference in dconf or expose a DBus API so that the image viewer can read it and stay in sync.
Photos as the full app in library mode should (and does) have its own sort settings since this is a different use case
Pinging @jeremypw on this for input from Files' point of view
@danrabbit Right, I'm only referring to the viewer - the library can have it's own sorting.
In Files itself, sort order is stored on a per directory basis, not as a setting. The filechooser, being a modified Gtk.FileChooserDialog takes most of its settings, including sort order from dconf path org.gtk.settings.filechooser. So, in order for these to b synchronised in the Image Viewer that app would have to read the directory metadata put there by Files (and vice versa).
@jeremypw Could you clarify?
In Files itself, sort order is stored on a per directory basis, not as a setting.
Could you clarify how that works? How / where that is stored? Or even more important how Photos should access that data. If I scan through the files code it looks like it's retrievable using GLib.FileInfo. It's stored as a "metadata::marlin-sort-column-id" attribute, which seems to be set here: https://github.com/elementary/files/blob/master/src/View/AbstractDirectoryView.vala#L3464-L3465 It also has something to do with a bit of c code in gof-file.
The filechooser, being a modified Gtk.FileChooserDialog takes most of its settings, including sort order from dconf path org.gtk.settings.filechooser.
But this doesn't really influence how Files works or the order in the viewer? In code it's called "direct mode" (and the other mode: "library mode") [1].
So, in order for these to b synchronised in the Image Viewer that app would have to read the directory metadata put there by Files (and vice versa).
why "(and vice versa)" ?
You are right that the sort information is stored in the fileinfo of the folder file itself and can be retrieved the same way as any other file attribute. In Files this is done in the core library, in gof-file.c:
if (file->is_directory) {
if (g_file_info_has_attribute (file->info, "metadata::marlin-sort-column-id"))
file->sort_column_id = fm_list_model_get_column_id_from_string (g_file_info_get_attribute_string (file->info, "metadata::marlin-sort-column-id"));
if (g_file_info_has_attribute (file->info, "metadata::marlin-sort-reversed"))
file->sort_order = !g_strcmp0 (g_file_info_get_attribute_string (file->info, "metadata::marlin-sort-reversed"), "true") ? GTK_SORT_DESCENDING : GTK_SORT_ASCENDING;
}
These attributes (if present) are used by Files to determine the display order in the view. If absent then the view is sorted by name.
I am not that familiar with the internals of Photos but it would be easy enough to translate the above code into Vala and query the fileinfo. Obviously, these attributes will only have been set if the folder has been opened in Files at some point.
The vice versa would only apply if Photos recorded its own sort order changes in the same attributes - in which case Files sort order would also be changed.
The FileChooser is separate code and does not use these attributes
Please add the ability to Photos Viewer to sort images like it's set in Files or at least add an option to set it in viewer manually.
I found an issue in design of image viewers. To reproduce:
Additional question: what if you didn't open a pic from file manager?
Launchpad Details: #LP1418266 Grzegorz G. - 2015-02-05 00:39:30 +0000