GNOME Bugzilla – Bug 448979
eog doesn't respect the way nautilus has ordered the pictures
Last modified: 2021-06-19 08:46:34 UTC
when you go through a group of selected pictures in eye of gnome, it is ordered what looks like based on name. eog should be integrated more with nautilus, where it follows the same sequence of ordering as nautilus does. eg. nautilus orders based on modification date, so does eog. if nautilus orders the pictures based on size, so does eog Other information:
there's also an Ubuntu bug about it: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/136740
Marking as an unversioned enhancement.
Please see an alternate (and superior) approach to the same issue: http://bugzilla.gnome.org/show_bug.cgi?id=590745
I have a similar problem, that is also related to the following excerpt from bug#590745: > When EoG opens multiple files, it > should present them in the same order EoG is passed them in." However my use case is not with nautilus but with the dev version of gPodder that handles image feeds: obviously the next step after having downloaded images with gPodder is to view them and eog looks like the perfect application to use for such a thing. Except that there does not seem to be a way to control the way eog displays the images (especially the order) from the command line. To be more precise, for a set of images b.jpeg, a.jpeg, c.jpeg (b.jpeg being the newest), the following command line will fail to display a slideshow showing the newest images first: $ eog -s b.jpeg a.jpeg c.jpeg Maybe there is a better way to "launch and talk to" eog ? If not maybe a command line option to force eog to restrict itself to what it is being told on command line would be nice ? Note: I hesitated between filing a new bug, or adding this comment to bug#590745, but as the later eventually refered to this one... Hopefully I made the good choice, but please tell me if not !
*** Bug 614341 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > I have a similar problem, that is also related to the following excerpt from > bug#590745: > > > When EoG opens multiple files, it > > should present them in the same order EoG is passed them in." > > However my use case is not with nautilus but with the dev version of gPodder > that handles image feeds: obviously the next step after having downloaded > images with gPodder is to view them and eog looks like the perfect application > to use for such a thing. > > Except that there does not seem to be a way to control the way eog displays the > images (especially the order) from the command line. > > To be more precise, for a set of images b.jpeg, a.jpeg, c.jpeg (b.jpeg being > the newest), the following command line will fail to display a slideshow > showing the newest images first: > > $ eog -s b.jpeg a.jpeg c.jpeg > > Maybe there is a better way to "launch and talk to" eog ? > > If not maybe a command line option to force eog to restrict itself to what it > is being told on command line would be nice ? > > Note: I hesitated between filing a new bug, or adding this comment to > bug#590745, but as the later eventually refered to this one... Hopefully I made > the good choice, but please tell me if not ! Thibauld, what you describe will require the general re-sorting support in eog (specifically by mtime in your case) discussed here and then likely a way to force it from the command line.
A mtime sorting would certainly help. However I can see some reasons why the mtime would not be the exact equivalent of the publication time of an item (the mtime would be more like the order of download *completion* I guess). I may be mistaken but I see eog as a simple "generic" image viewer for the platform and as such it would make sense for it to allow a slightly easier communication with external apps, like for instance allowing an app (wether nautilus, gpodder or even 'ls' or 'find') to force an arbitrary "playlist" order instead of trying to workaround one or two automatic hardcoded sorting methods. I would see it for instance like that: 1/ opening an image "eog myImage.jpeg" Which obviously displays the desired image but also "looks around" the folder and display the neighbouring images => this is the default behaviour of eog as I understand and experience it, and I find it really *good*, *useful* and *coherent* with what most others image viewers do 2/ opening several images "eog B.jpeg C.jpeg A.jpeg" Which displays B.jpeg and offers to navigate among other images: restricting itself to the images given on the command line and enforcing the exact order set on the cmmand line. This way, any external application would only need to know that the image viewer is called "eog", arrange the images to be displayed as they should and without worrying about the viewer, and it would eventually "just work" (well I guess...).
*** Bug 628407 has been marked as a duplicate of this bug. ***
An internal sorting of eog should only be an option, after all people use linux because it gives more choice. It should be possible to disable any sorting, so that if someone types eog b.jpg a.jpg she/he should be able to see picture b.jpg first and picture a.jpg second. More importantly, the "sorting mode" of the present version of eog behaves badly with folders. Suppose you have folder 1/ containing files a.jpg and c.jpg and folder 2/ containing files b.jpg and d.jpg If you type eog 1/ 2/ you see all pictures, in the incorrect "name-only" sequence a.jpg b.jpg c.jpg d.jpg, not the correct 1/a.jpg 1/c.jpg 2/b.jpg 2/d.jpg This behavior is very bad if you organize your pictures in folders related to individual days or occasions, but containing pictures from different cameras with different naming conventions. Please correct the sorting routine of eog so that it is based on the full pathname, not just the basename! Thanx, Nick
"An internal sorting of eog should only be an option, after all people use linux because it gives more choice." Can we please get this misconception out of the way forever? This is not GNOME's goal, but KDE's. Let's pick a good default that solves the current disconnect between Nautilus order and EOG order and stick with it. I suspect that most GNOME users open pictures by clicking them in Nautilus as opposed to File -> Open, so I opt for using the Nautilus order.
I only want to say that all of you guys who want to see eog being well integrated with the command line are missing the point of the direction where the desktop is moving.. With regard to this bug, I am not very inclined to add any other sorting criteria than the existing filename one. Honestly, filesize, mtime, mimetype, etc. are all very uninteresting criteria for an average user who probably doesn't know what a filesize or mimetype is. Let's not forget that eog aims to be a simple image viewer and not a powerful image browsing tool. For that, you better find different software. (if anything, the only sorting criteria that I find interesting to have is the exif datetaken field, in case you dump pictures from different cameras into one folder and want to browse them in the order they were taken)
OK, forget about choice. At least let us have the nautilus sorting, which is 1/a.jpg 1/c.jpg 2/b.jpg 2/d.jpg By the way this "nautilus" sorting is the standard for unix command line programs, e.g. it is the same order of text file viewing programs. In a parallel situation with txt instead of jpg: cat 1/* 2/* or less 1/* 2/* would display these files in the order 1/a.txt 1/c.txt 2/b.txt 2/d.txt not the eog one: 1/a.txt 2/b.txt 1/c.txt 2/d.txt The exif sorting Saavedra mentions is also nice, but that takes real coding! The bug correction I am requesting is probably a tiny simplification of the code, something equivalent to removing a "basename" somewhere. Of course I could look for it through the source and recompile eog myself, but it would be better that everybody benefits of this improvement. Many thanx to whoever will fix it! Nick
(In reply to comment #11) > (if anything, the only sorting criteria that I find interesting to have is the > exif datetaken field, in case you dump pictures from different cameras into one > folder and want to browse them in the order they were taken) My father just took the plunge after seeing my brother using gnome the last few months, so when I came home for a visit he asked me to install it and remove his Windows installation. The first thing we did after installing was to dump in his 3-gigabyte photo collection of photos taken with over 5 different cameras by 3 different users all sorted in folders according to the occation or period. He was immediately at home with Nautilus, selecting View->Arrange items by->Modification date, and then proceeded to doubleclick an image in the middle of a folder (opening it in EoG), and clicking next/previous, and noting that it did not show the images in the same order as the file browser - which Windows does. I told him I'd get online here and file a ticket, and found this :) I don't think sorting by EXIF datetaken field would be very intuitive - I think the only intuitive thing to do in this circumstance is to follow the sort order that Nautilus uses for the current folder. Anything else would certainly confuse my dad.
*** Bug 682611 has been marked as a duplicate of this bug. ***
Created attachment 225119 [details] [review] Add support for 6 image gallery algorithms
I uploaded a patch that adds support for 6 image gallery sorting algorithms and a command line option for selecting the one used. Option: --sort=N Valid values for N are 0-5: 0 - sort by filename 1 - sort by filename (reverse) 2 - sort by modification time 3 - sort by modification time (reverse) 4 - sort by filesize 5 - sort by filesize (reverse) The default value used is 0.
As a normal Ubuntu user, plagued with this problem when showing pictures to Windows users, I'm really pleased that this problem has been solved. How can I implement the solution on my system? The attachment looks to my untutored eyes like the output of a diff comparison. How can I use this to update/upgrade my installation? I'd be most grateful for any hints & tips.
*** Bug 711213 has been marked as a duplicate of this bug. ***
EOG should support the ordering of files offered by Nautilus. On my part, I use Nemo and the file ordering are 'Manual', 'Name', 'Size', 'Type', 'Detailed Type' and 'Modification Date'. There is surely a way for EOG to detect the ordering options of any file browser and use them. I mostly use 'Modification Date', because it the closest to the creation dates of file. When I browse pictures that have a filename that is not meaningful and that were added gradually to a folder, I want to browse them by 'Modification Date' in EOG, this is currently not possible and it is not practical right now.
In case someone needs an image viewer that does it right, use gThumb. Go in View->Filter to make it open only images (else videos will get in the way). You must use Page Up and Page Down to cycle through pictures. You can adjust the sorting in View->Sorting.
*** Bug 782293 has been marked as a duplicate of this bug. ***
If I understand correctly, couldn't this be solved with a dconf key and some adjustments to Nautilus and EOG? Here's what I'm thinking: dconf: Add a dconf key that can be used with any file manager or image viewer (that's right, not limited to Nautilus and EOG). The value of the key would be a comma-separated list of image viewers that support a sorting parameter. EOG: Add an optional sorting parameter (optional so there's no problem with file managers that don't support this). If the file manager includes this parameter when calling EOG, then the files are to be sorted in that order. Nautilus: When an image or selection of images is opened, check if the aforementioned dconf key exists and lists the image viewer being called. If yes, then include the sorting parameter according to the image directory. Of course, the sorting parameter and its values need to be fixed. It can be something like --sort={Name | Size | Time | ReverseName | ReverseSize | ReverseTime}
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/eog/-/issues/ Thank you for your understanding and your help.