Does it change the event picture permanently?

no, it does not

If there is interest in having this feature in Shotwell. I will make the shown Image change back to the primary image when the mouse leaves an EventItem

Review of attachment 368942 [details] [review]:

Did you try it with very large events? it already looks quite flickery with ~55 pictures

::: src/events/EventDirectoryItem.vala
@@ +170,3 @@
+        int element_index = (int) Math.round( (double) x / width * (event.get_media_count() - 1) );
+        unowned MediaSource media = event.get_media().to_array()[element_index];
+

The continous conversion to array could turn out to be annoying for very large collections, but I currently see no easier way

(In reply to carsten.csiky from comment #3)
> If there is interest in having this feature in Shotwell. I will make the
> shown Image change back to the primary image when the mouse leaves an
> EventItem

That would be a plus, because that's what confused me.

From my POV I would like to take it in, after feature freeze (which Shotwell is currently in, in alignment with GNOME schedule)

(In reply to Jens Georg from comment #4)
> Review of attachment 368942 [details] [review] [review]:
> 
> Did you try it with very large events? it already looks quite flickery with
> ~55 pictures
> 
> ::: src/events/EventDirectoryItem.vala
> @@ +170,3 @@
> +        int element_index = (int) Math.round( (double) x / width *
> (event.get_media_count() - 1) );
> +        unowned MediaSource media =
> event.get_media().to_array()[element_index];
> +
> 
> The continous conversion to array could turn out to be annoying for very
> large collections, but I currently see no easier way

I quite dislike that as well. The only way I have seen for improving that would be caching the array. Is there a better way?

(In reply to Jens Georg from comment #4)
> Review of attachment 368942 [details] [review] [review]:
> 
> Did you try it with very large events? it already looks quite flickery with
> ~55 pictures
> 
> ::: src/events/EventDirectoryItem.vala
> @@ +170,3 @@
> +        int element_index = (int) Math.round( (double) x / width *
> (event.get_media_count() - 1) );
> +        unowned MediaSource media =
> event.get_media().to_array()[element_index];
> +
> 
> The continous conversion to array could turn out to be annoying for very
> large collections, but I currently see no easier way

About the flickering: Do you mean "flickery" caused by the users mouse movement or by bad performance.

In terms of performance, I did not experience any problems with events up to ~400 pictures (testing on an i5-5200U, 12G Ram and SSD, which is definitely above what the minimum requirement should be for having this feature work properly)

I created a basic version, that implements the "show thumbnail on mouse leave" like this: https://github.com/GNOME/shotwell/compare/master...csicar:master.diff

Needed refactoring in that patch: 
- I changed the name of "highlighted" in Page.vala to "current_hovered_item", since it is now also used for this purpose. 
- Created "handle_mouse_leave()" and "handle_mouse_enter()" and use there methods for the highlight() and unhighlight() methods

I'm sorry, I somewhat forgot about this. I will take a look. With flickery I meant the mouse movement when the event carries many photos

The Solution could be limiting the minimum hover-width, where an image will be displayed. Like this: https://gitlab.gnome.org/csicar/shotwell/compare/image-scrubbing...image-non-flickery-scrubbing

Cool. I think % 15 is enough.

Can you squash the refactor commit into the relevant previous commits and open a merge request?

here is the merge request https://gitlab.gnome.org/GNOME/shotwell/merge_requests/3