GNOME Bugzilla – Bug 590745
Next/Prev overcomplicated and unintuitive
Last modified: 2021-06-19 08:45:39 UTC
eog seems to manage the entire directory of files, regardless of whether a user opened multiple files or a single file. Without having done any profiling to back this up, I would imagine this has adverse effects on startup performance when a user really only wants to look at one image but the application builds up a list of all the images in the directory. The unintuitiveness aspect is that next/prev appear to ignore Nautilus sort order. This is a separate issue, but it seems like it is likely closely related.
From the corresponding Launchpad bug (https://bugs.edge.launchpad.net/hundredpapercuts/+bug/388500): "When the user opens a single image in EoG, the application currently does /much more/ than the user is asking by allowing the user to step through all images in the same directory of the image opened. This feature often unnecessarily slows down launching EoG when the user is interested in viewing only one image. The solution to this problem is to make EoG behave like other applications: when the user opens one file, display one file. If the user wishes to view an entire directory of images, the user should open that directory in EoG, or select multiple files and open them. When opening a directory, EoG should use its own sorting. When EoG opens multiple files, it should present them in the same order EoG is passed them in."
(In reply to comment #0) > eog seems to manage the entire directory of files, regardless of whether a user > opened multiple files or a single file. > > Without having done any profiling to back this up, I would imagine this has > adverse effects on startup performance when a user really only wants to look at > one image but the application builds up a list of all the images in the > directory. Known issue, see bug 495825. > > The unintuitiveness aspect is that next/prev appear to ignore Nautilus sort > order. This is a separate issue, but it seems like it is likely closely > related. > Ditto, see bug 448979.
Note that the problem being addressed here isn't that Nautilus takes too long to start (bug 495825) or that EoG unconditionally alphabetizes photos before showing them (bug 448979), but that EoG does more than the user is asking for when it offers to flip through all photos in the same directory when a single photo is opened.
(In reply to comment #3) > Note that the problem being addressed here isn't that Nautilus takes too long > to start (bug 495825) That bug is about eog.
Sorry, Claudio, typo! Note that the problem being addressed here isn't that EoG takes too long to start (bug 495825) or that EoG unconditionally alphabetizes photos before showing them (bug 448979), but that EoG does more than the user is asking for when it offers to flip through all photos in the same directory when a single photo is opened. In a folder containing five images, select two photos in Nautilus and open them, and EoG displays two photos ("1/2" is displayed in the status bar). Now open one photo in the same folder in another EoG instance, and EoG displays three photos ("1/3" is displayed in the status bar).
(In reply to comment #0) > eog seems to manage the entire directory of files, regardless of whether a user > opened multiple files or a single file. > > Without having done any profiling to back this up, I would imagine this has > adverse effects on startup performance when a user really only wants to look at > one image but the application builds up a list of all the images in the > directory. > > The unintuitiveness aspect is that next/prev appear to ignore Nautilus sort > order. This is a separate issue, but it seems like it is likely closely > related. The performance problem should not be an argument to change the current behavior and UI. Having to open and close eog for each image would be *really* annoying. The case of seeing only one image is quite rare actually. Most of the time, users are dealing with lots of images and they want to easily see them without distractions. Keep in mind that images are not like office documents or videos that you usually view one per time. Also worth mentioning that opening a *directory* with an *image viewer* is way more unintuitive... Anyway, it shouldn't be difficult to make sure eog opens and loads selected image as fast as possible and loads image list later in the process. In other words, the number of images in the same directory than the opened image should not influence startup time. This is something I've been planning to do for a long time but didn't have time...
(In reply to comment #0) > eog seems to manage the entire directory of files, regardless of whether a user > opened multiple files or a single file. > This is actually the behavior many known image viewers have (e.g. Windows built-in, Irfanview) and is the first time I hear a complaint about that. From the bug reports and the feedback we get through the mailing list from time to time I have the impression that this is actually a quite well-received feature. > Without having done any profiling to back this up, I would imagine this has > adverse effects on startup performance when a user really only wants to look at > one image but the application builds up a list of all the images in the > directory. > The penalty should be pretty small on local disks. We are aware of the fact that it could be a problem over network links as image loading doesn't start before the folder was enumerated. We have ideas for improvement here but currently lack the time to implement them. > The unintuitiveness aspect is that next/prev appear to ignore Nautilus sort > order. This is a separate issue, but it seems like it is likely closely > related. > This could be fixed by the new GIO metadata storage which will allow us to get information about the sort order used by nautilus in that specific folder. But that's as Claudio already wrote different issue. (In reply to comment #1) > From the corresponding Launchpad bug > (https://bugs.edge.launchpad.net/hundredpapercuts/+bug/388500): > > "When the user opens a single image in EoG, the application currently does > /much more/ than the user is asking by allowing the user to step through all > images in the same directory of the image opened. This feature often > unnecessarily slows down launching EoG when the user is interested in viewing > only one image. see above > The solution to this problem is to make EoG behave like other > applications: when the user opens one file, display one file. If the user > wishes to view an entire directory of images, the user should open that > directory in EoG, or select multiple files and open them. When opening a > directory, EoG should use its own sorting. Some thoughts on that: 1. Most distros hide eog from the menu to have it appear that eog and nautilus belong together (like the image preview and the explorer under windows). This would have to be reverted. This is probably the smallest problem. 2. It will make browsing images quite a bit more work. The user has to launch eog, click "open folder", search the target folder, click open. 3. Opening multiple images from the file manager is in my opinion equally strange as it requires to select the images and then you need use either the right click menu (which can be quite large if you have many image viewers/editors installed) or you have to switch over to the keyboard to hit "Enter". (2.) and (3.) are far away from the comfort of a double click (or if nautilus is configured respectively even a single click). 3. I'd rather not add the folder mimetype to eog as this can easily break nautilus so far that every folder is opened in eog. This would be a requirement to have eog in the right click menu for folders. 4. There are people complaining that they have to press a button to save their changes (bug 338138), guess what they will say if they need to go through the procedure mentioned in (2.) just to browse a folder full of pictures. > When EoG opens multiple files, it > should present them in the same order EoG is passed them in." > That's a different story (your own bug 590748) and likely requires a fix for bug 448979 to build upon.
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.