✨ resize image window

[danton267]

When the app starts, we get initial width and height, which is then used to create the initial figure.
When a resize event happens for whatever reason (full screen, zoom, manual sizing, etc...) resize_window_event will trigger, which will then update the figure and viewfinder, and metadata for future callbacks.
The figure is updated in such a way that it will always fit into the screen size.

This takes over #93, which can be deleted. Thanks, @cleaaum, for the nice start 🔥

[github-actions]

Staging application has been deployed and is available at: https://dash5-services.plotly.host/ml-exchange-staging
Production app name: ml-exchange
Current branch name: relayout-screen-size
Commit: c92a9d3

[cleaaum]

This works well when the image has not been zoomed in yet ✨ ! However it does not seem to work after the image has been zoomed in. By this, I mean that the zoom level of the image is not persisted after the window is resized.

[danton267]

@cleaaum that is an intended behaviour. What could happen is that when the window is resized the image itself could go out of bounds and would "disappear", hence I made it also re-center in the middle

can change it back to keeping the zoom but it can cause wonky behaviour

my thinking: the user is not going to be changing their window size often, and when they do, it's better so that they can see the entire image relative to their new window size, rather than for it to disappear out of the window, and even if it didn't disappear
because they changed the window size, they would have to zoom in/out to make it fit again anyway.
Better UX IMO

[hannahker]

Is it possible to switch this to a clientside callback for better performance?

[danton267]

I don't see why not

[cleaaum]

That's what I did the first time I did this, but @hannahker mentioned that the zoom level should be maintained. I personally don't love the fact that it recenters (especially because there is a recenter button now). I don't see how it would cause wonky behaviour (at least I didn't notice it when I implemented it!)

Also, getting the browser dimensions to fit the screen resizing without preserving the zoom level worked before I think, but I could be wrong, it was a while ago. Anyways just my ideas! Hannah can decide which behaviour is ideal:)

[hannahker]

I'd agree with @cleaaum on this one. In testing this out I found it surprising that the image would reset to the zoomed out view, and I'd imagine that this could be frustrating to users who would now have to zoom in again and find their "place" in the image.

I'm not sure if it's a lag or a bug, but I'm also finding that the resizing isn't working as I'd expect in all cases. See demo below where I end up with some white space on the top and bottom of the image, when I'd expect it to take up the full available height.

Screen.Recording.2023-09-21.at.1.45.38.PM.mov

[danton267]

will adjust it to keep the zoom and relative position tomorrow

re: "lag" part, I am not sure about that, never happened on my end.

[hannahker]

@danton267 I'm getting that issue on Firefox when checking the deployed staging link. Can you reproduce the issue there?

[danton267]

I pushed all my WIP.

Current issues:

1. when a resize event happens, the figure is resized, however, the "boundary bars" around the figure still remain and are "squishing the figure in".
   • these boundaries disappear as soon as any relayout event happens (when the user zooms in/pans)
   • I tried triggering another callback that would do this but it would not work
2. using recenter works fine every time, however, after the user uses "recenter" button the first time, now when the screen size changes, the figure will be recentered below the screen (somewhere somehow it must be switching y0 y1)
   • I tried fixing this by monitoring all x01y01 but I could not find the solution, this is doubly perplexing since reset_figure_view does not update anything that could then change the image_center_coor value

[hannahker]

Closing for now. See comment here: #89 (comment)