guaranteed "back" feature

[chupacabra]

I sometimes run into an issue where I unexpectedly end up at the end of a folder. i.e., I'm looking at a picture in the middle of directory "xyz" and fat finger some weird key/key combination and suddenly it jumps to the end of the directory. Also there are several bugs that I've reported that cause this same behavior. The problem is how do I get back to where I was? Ctrl-Z usually doesn't help. So now I have to start scrolling back up until I find where I was working.

Can you please keep track of the last image selected and provide a fail-proof mechanism to allow the user to return to last selected photo no matter what?

I've run into this problem so many times since I started using imatch awhile back.

[Mario]

Which problems did you report that lead to a wrong image being selection (thread links please)?

IMatch keeps track of the last selection (in case you accidentally deselect files and want to restore it), but it does not store which images you have focused and in which order.
I'm not really seeing much purpose in this and AFAIK this was never before requested. I could add one (or more, in case you often accidentally select several wrong files) to the Undo mechanism. Let's see how many other users have this issue and +1 this.

If these happens often to you, I recommend you set a bookmark. And then just go back to the bookmark when you accidentally press <End> or <Home> or whatever causes the problem.
See File Window Navigation in the Keyboard Cheat Sheet

[sinus]

+1

This happen to me also from time to time, although not very often.
That IMatch keeps track of the last selection, was a very good thing, what you introduced once.

For me this is a logical enhancement, what would fit into this field ... "when you are lost in images, it would be nice to find back again".

[twe]

The app "recently used" keeps track of images viewed and in what order, and will get you back to where you were. But the app has to be running to be useful...

[Mario]

The "Undo Selection change" feature already does (most) of this - if there is a selection of more than one file.
I have explicitly excluded a simple change or the focused file to not fill the Undo buffer with (in virtually most cases) unneeded data, probably flushing out important things like "undo metadata change" or similar.

If a user navigates between files using cursor keys, clicking with the mouse, using the PageUp or PageDown or the special shortcuts to go to the next/previous image in the MD and KW panels for super-fast editing, should IMatch really put these onto the Undo stack? Or just the last one? Should all <remember file> steps be removed when something like <set rating> or <toggle bookmark> is added as an undo step? Because in order to revisit the previous locations, you would have to undo the <set rating> or <toggle bookmark> as well - which is probably not useful.

So we maybe should store only one "I moved from file A to B" step, so you can go back to A if you accidentally moved to file B? And only if there is no other undo step added afterwards? Not sure how often this really happens.
I've added the "undo selection" because I found it to be a pest to accidentally click outside a selected file and then have to re-do the selection.
But accidentally pressing <Home> or <End> or something that really moves the focused file to a totally different place (cursor keys or page up/down don't move than far).

Under which conditions do you accidentally focus a distant file?

[ubacher]

This going to the end of the folder happens to me a lot. I think it is associated with Imatch repainting the thumbnail window
because something has changed. It is annoying, especially if it happens repeatedly.

I think an option to repaint (refresh) the screen only on manual request (with a corresponding button) would
help. To make the user aware that (visible) changes are outstanding some indicator would need to be set (the refresh button color?)

(A related problem: I scroll down the display - Imatch gets around to repaint the screen - and my screen rolls back to show the last
selected image. Since one does not normally know when Imatch does repaints this can only be avoided by selecting a file on the current screen
after each scrolling down. One has to be fast though to do this before a repaint happens - this is a real nuisance for me.

The proper dealing with this would be to refresh the screen to the setting it was at before the refresh. This information may not be available
to Imatch proper.

[Mario]

Refreshing the File Window does not change focused file or selection, unless files are removed which were selected/focused.

Many operations users trigger can require the File Window to reload in order to show valid data. This mostly depends on the user's workflow, e.g. modifying the category you are currently viewing, which is not necessarily a good workflow.

When a File Window refreshes because it received events on the IMatch event bus, it maintains the selection and focus and keeps the focused File Visible.
In the rare case that you were actively scrolling the File Window without changing the focused file (wheel or scrollbar), this may interfere. But I'm quite sure that this is really rare, until you actively change what you are looking at or the folder you are working on is currently updated because or new or modified or deleted files.

The proper dealing with this would be to refresh the screen to the setting it was at before the refresh.

This is what IMatch does.
But this is not what this feature request is about. This feature request is how to deal with situation where users accidentally focusing a wrong file by direct interaction. And don't find the file anymore or similar.
Bookmarks work well. The Recently Used app works well. Undo only works when a selection existed which was changed, not when the user just clicked on another file or moved the focus otherwise by accident.

[chupacabra]

When this happens it does not happen by my choice - I have reported one or more issues related to having "hide rejected files" selected and deleting files with this filter enabled that sometimes causes it to jump to the end of the directory. Sometimes I  hit some key by accident that causes the same problem. Since it is not a conscious choice, setting a bookmark each time I select an image seems impractical and I would never remember to do it each time I moved to a new image.

Is there a common "select file" procedure/function/method where you could set a "last file selected" variable when any new file is selected? That way, returning to the previously selected image might be straight-forward to add. Maybe.

I'll try to find the issue(s?) with "hide rejected files" I wrote up previously. You said you weren't able to repro it and asked me to see if it occurs in the 2021 imatch release. I just got notice of that release and haven't tried it yet (can I demo the new release and still keep my existing imatch version active?).

Please see post:

    "imatch goes to end of set after rejecting an image from a filtered set"
    « on: May 02, 2021, 02:58:47 AM »

[Mario]

I have worked on that a couple of months ago, I believe. Don't remember.
Please check the detailed release notes for IMatch 2021 here: https://www.photools.com/release-notes/?productId=443

You can install the trial version of IMatch 2021 on a PC and try it there.
Do not install the trial version on top of IMatch 2021, this is not supported. The trial version would open your database in read-only mode only anyway.