BestImageViewer
"Delete" key deletes ALL the displayed files instead of just one
- Bug Report
GEEQIE VERSION
Geeqie 1.6+git20210130-5e1d3224 GTK3
Latest from git as of today
GTK-3
OS / DISTRIBUTION
Debian/sid
SUMMARY
This is a change from previous behavior. ALL displayed images are deleted now, instead of just the one we're currently looking at.
STEPS TO REPRODUCE
geeqie 1.jpg 2.jpg 3.jpg. We're looking at1.jpg, and geeqie knows that we care about those 3 files only, so pgup/pgdown cycles between those 3 files- "Delete" on the keyboard. Previously only
1.jpg(what we're looking at) would be deleted. Now ALL 3 files are deleted
Additionally, after we press "Delete" and the requested files no longer exist, geeqie then displays the other files in the same directory. The user didn't ask to see those files, and it shouldn't show those. It should display some sort of "no images selected" message, or something.
I'm wondering if the "right" way to solve these issues is to break the connection between the files listed in the left bar, and the files in the directory on disk. Instead, the files being displayed should appear in that list. That would make it clear to the user what Geeqie is doing. Thanks.
The original design was that a command of the format
geeqie <filelist>
would open the folder containing the files, and would create a hidden collection window containing those files. Keyboard commands worked on the hidden collection window. I thought this design to be very confusing.
At the moment:
a command of the format
geeqie <filename>
opens the folder containing that file, and selects that file. I think this is what the user expects.
a command of the format
geeqie <filelist>
opens the folder containing those files, and selects the files in the list. I think this also is what (most) users would expect.
a command of the format
geeqie --list <filelist>
opens the folder containing the files, and also opens a collection window containing the file list
Perhaps this last option gets closer to what you expect. Unfortunately there are commands that work in the main window but do not work in a collection window - rotate image for instance.
I guess that could be seen as a bug or a missing feature.
Hi.
No idea how common this is, but 100% of my geeqie usage is
geeqie a.jpg b.jpg c.jpg
where each argument is a file I want to look at. Sometimes I look at just one file, sometimes I look at many, but it's never 0, and I never ask for directories. If I want to see all files in a directory, I
geeqie *.jpg
So from that perspective, it's at best not useful to have geeqie show a directory listing. I already looked at the directory in the shell, and I already picked the files I want to see.
I don't know how much work this would be, but I think it makes more sense to show the files the user asked for, instead of the contents of the directory. This would remove much of the UI confusion.
And reading your description of the current behavior, I now see another UI quirk: what happens if you
geeqie directory1/a.jpg directory2/b.jpg
? The pane can only display one directory at a time, so in this case it can't show all the files in the directory, selecting the ones the user requested. Instead it opens an explicit collections window (which is a separate window, not a pane, so it's very qualitatively different in a tiling WM). Navigation is no longer cyclical, so #862 doesn't apply. And at exit time it asks me if I want to save the collection. This isn't nice; the UI shouldn't change if my files are split over multiple directories. Displaying the requested files in the pane would handle this nicely too, I think.
Strong feelings?
The original implementation when a file list was on the command line, was to open a collection but hide the collection window from the user. I think that is very confusing, and I would prefer not to go back to that.
When files from multiple directories are on the command line, the only option to show them to the user is a collection window.
The files pane is shown by two modules - view-list and view-icon. Both modules display a list of filedatas. In the current implementation the list is always the filedatas of the currently selected directory. Therefore, simplistically, it would seem possible to feed those modules a list of any set of filedatas.
In that case the folder pane and path entry box would become irrelevant, but cannot be simply blanked because the user needs to be able to navigate away.
The filedatas displayed could be either a set of files the user has specified on the command line, or a collection.
The user interface for a collection is not the same as the normal files pane. When a normal files pane is displayed, the user is operating on files. When a collection window is displayed, the user is not operating on files, but on links to files.
I would like to eliminate the separate collection windows and integrate them into the file pane - but there will be difficulties.
With the current design it is possible to view and operate on a subset of the files in a single directory, but is a little convoluted.
When a set of files is selected, execute Toggle Mark 1 - default accelerator is 1
Execute Filter Mark 1 - no default accelerator.
- but using Marks can make things a bit slow...
Hi. Maybe the "right" thing to do is to make both a "collection" and a "file" list as toggle-able pane elements. I guess in that case selecting anything in the file list would overwrite whatever is currently in the collection. That's weird, but probably allows both kinds of usages.