Rework the model loading to not care about the edges.
Now we only care about where we are in the model and
the number of buffer pages. This algorithm handles
the edges without special casing.
Previously we loaded images synchronously and manually
changed `LpImage`. This could cause freezes when loading
large images and SVGs. We also had no proper feedback for
when a corrupted or unsupported image was loaded.
This commit introduces a major rework to how we handle
images and the gallery. It introduces a swipeable gallery
that loads files asynchronously via a new widget: LpImagePage.
LpImagePage owns the file and information related to the file,
and on creation it spawns a future that either loads an error
page when it can't load something (file deleted, corrupted, or
unsupported) or the actual image via LpImage. LpImagePage
now holds the right-click popover and the associated gestures.
The gestures needed to be moved to LpImagePage in order to
rework LpImageView's overlay - instead of having an overlay
child that's a box with a few buttons, we now have the buttons
as individual overlay children. This could cause them
to overlap each other at certain sizes, but it's required
in order to allow input to reach the carousel below.
Right now this comes with a few regressions:
* Occasionally input gets blocked across the applications. It's
hard to tell if this is caused by swipes or right clicking. This
input issue can cause a crash - no Rust backtrace, so a debugger
is needed.
* The "current" page doesn't seem to be properly loaded by the
time `set_image_from_file ()` finishes, so we need to rework
resizing from image dimensions
* We need to re-implement loading different directories and
files within directories
There also seems to be an issue on touchscreens, swiping between
images on a touchscreen causes responsiveness issues not present
when swiping on a touchpad. My guess is that it's related to
the long press gesture.
Calling `xdg-open` is the wrong thing to do, and has
flaky reliability. What we want is to use the portal
directly with the exact behavior we want.
When using the portal we can't just pass the uri -
we need to own a file descriptor.
This gives users a very intuitive way to open files.
The gesture was awkard and didn't match any common patterns
across GNOME. The button is simple and obvious.
This will make writing libadwaita-based code a bit
nicer, and make it nicer when we use crates that
libadwaita's API re-exports.
Also clean up the unused imports exposed by
this change.
This is one of the features we need for the MVP,
but printing is a bit beyond my current knowledge.
So, I need to research this. Onto other things for
now, so I'll add note.
We don't need to load the file twice just to get the
dimensions. We can load a GdkTexture, use it's APIs
for the width and height, and return that as a result
to the window. This allows us to kill the `dimensions-loaded`
signal and one of the places where we need to load a file.
