keeper 0.5.1

keeper 0.5.1

nothing about your archives changes and nothing about how you install it
changes. an existing .keeper folder is read and written exactly as 0.5.0
left it, and an installed keeper can update itself to this one from inside its
own window.

on a mac, if you do not have it yet:

curl -L -o ~/Downloads/keeper.tar.gz https://github.com/gntrs/keeper/releases/latest/download/keeper-macos-arm64.tar.gz
tar -xzf ~/Downloads/keeper.tar.gz -C /Applications

on windows, run keeper-0.5.1-windows-x64-setup.exe.

against 0.5.0

	0.5.0	0.5.1
dragging a frame out, on windows	the drop panel covered the app	nothing, the drag just goes
dragging a frame out, on a mac	fine	fine
dropping a folder in	works	works
a raw frame in the quick look	looks like any other frame	says raw in the corner
what a raw exports as	a jpeg off the 3072px proxy	a jpeg off the 3072px proxy
downloads	same four, same sizes	same four, same sizes

what we did not have, and now do

dragging a photograph out of keeper works on windows. this is the whole
release. a drag belongs to keeper's drop panel when somebody dragged a folder
in from their file manager, and the test for that was that keeper's own drags
carry a private mime type while a real folder carries Files. on windows that
is not true. dragging a frame out has to hand the other application a real
file, so keeper puts a DownloadURL on the drag, and chrome on windows
answers that by synthesising a virtual file and listing Files in the types.
the drag matched keeper's own test, and the full screen "drop it here" panel
slammed up over the app the instant anybody started dragging a photograph out
of it.

it was never seen on a mac, where the same code is dragged out of daily, so
the two platforms simply disagree about what that kind of drag is carrying.
the question is asked the right way round now: a drag carrying one of keeper's
own types is keeper's, whatever else is on it. underneath that is a second
guard for a windows that strips the custom types out of the list, and that
guard expires after a second and a half of silence, because a drag released
over another application does not reliably say so and a guard stuck on would
leave keeper unable to accept a folder at all.

a negative says so in the corner of the preview. no browser draws an arw,
so a raw is shown and exported through a jpeg preview keeper decoded out of it
once, capped at 3072 on the long edge. nothing on the card was ever wrong
about that: the index measures the proxy, so the resolution printed under the
picture is the honest ceiling and the bench's too-small warning is computed
against the same pixels. what the mark says is the one thing the card
otherwise cannot, which is that the file on your drive holds more than keeper
is showing you. a 33mp negative carries better than twice the detail of the
proxy cut out of it, so a frame headed for print is a trip to the original
rather than to keeper's export folder.

what got more expensive

nothing measurable. the drop guard is a few lines and one flag, the mark
is one element that only exists while a negative is open, and the four
downloads are the same sizes they were.

what we still do not have

the windows fix has not been run on windows. it is fixed against the
behaviour chrome on windows is documented to have and the guard was tested
against both shapes that behaviour can take, including the one where the
custom types are stripped, but every one of those tests ran on a mac. if
dragging out is still wrong on your machine, that is worth saying out loud
rather than working around.

the raw mark has not been seen against a real negative. the set of
extensions it keys off is the same one the decoder uses and it was checked
against every raw format keeper reads, but the archive it was drawn over was
jpegs with the flag forced on.

no signature and no notarisation, same as 0.5.0. the two lines above walk
around a warning rather than removing it.