keeper v0.9.3

the notes are written by hand before this is published.

keeper v0.8.0

an installed keeper updates itself to this. what keeper depends on did not change, so the update is the 0.40 mb payload rather than a whole download. press the version in the corner, or turn updates on in settings under ?.

a fresh install is below. on a mac:

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

	0.7.0	0.8.0
the downloads tab	a card in the middle of the window	a desk that uses it
what a download says	one log, raw	plain steps, or every line, your choice
what it saves	mp3	mp3, m4a, the original audio, or video
how good	whatever mp3 came out at	max, good or small
dependencies	sharp	sharp
doctor checks	9	9

what we did not have, and now do

the same run, told two ways, and you pick. simple is five short lines that tick off: reading the link, picking the best quality, downloading, converting the file, adding the title and artwork. full is every line the programs printed, in the face they printed it in.

those are two different people. somebody who does not write software should not have to work out that [info] Downloading 1 format(s): 251 was a good thing. somebody who wants to know exactly what ran on their machine must not be handed a summary and asked to trust it. the plain view is built out of the raw lines rather than instead of them, so turning full on halfway through a download shows the whole run from its first line. nothing is thrown away to make the short version, which is the only way the short version is safe to offer.

you choose what comes down. mp3 because it plays in everything, m4a for the same quality in a smaller file, the original audio with no re-encoding at all, or the video as an mp4.

max is not a preset. it asks for the best the link actually offers, and for video that is the best picture plus the best sound, merged. measured on one link: max came down as 3840x2160, small as 1280x720, and the same link as mp3 was 20 mb at max and 6.4 mb at small. a source that only has 720 gives you 720 at max, because that is what it has.

keeper tags its own lines now. an untagged line used to be attributed to keeper for having no tag, which quietly credited yt-dlp's sentences to us in the one view whose whole job is being literal about where words came from.

what got more expensive

the payload grew by about nine kilobytes. no new dependency, so an installed keeper still swaps source files rather than downloading a runtime it already has.

video is a much bigger file than audio, and nothing warns you before it starts. the same three minute link is 6.4 mb as a small mp3 and 724 mb as max video. there is still no way to stop a download once it is running.

what we still do not have

none of this has run on windows. not the new tab, not the binary fetch, not the paths. the code names the .exe assets and looks in the winget, scoop, chocolatey and program files folders for ffmpeg, and that is reasoning rather than a test. the same caveat has been on every keeper release so far and it is still true.

no way to stop a download. close the tab and it carries on until it finishes.

one track a link. an album or a playlist link is turned down with a note saying so, rather than quietly downloading the first of eighteen.

ffmpeg still has to be on the machine already, for every format including video, and a track spotDL cannot find on youtube cannot be downloaded, because youtube is the only place the audio is actually coming from.

keeper v0.7.0

an installed keeper updates itself to this. what keeper depends on did not change, so the update is the 0.40 mb payload rather than a whole download. press the version in the corner, or turn updates on in settings under ?.

a fresh install is below. on a mac:

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

	0.6.3	0.7.0
views	shelf, bench	shelf, bench, downloads
things that can reach the internet	1, the update check	2, and both ask first
what keeper fetches that is not keeper	nothing	yt-dlp and spotDL, once, on a yes
update payload	0.36 mb	0.40 mb
dependencies	sharp	sharp
doctor checks	9	9
runs with the wifi off	everything	everything except the new tab

what we did not have, and now do

audio off a youtube or spotify link, as an mp3, into a folder you pick. a third tab next to shelf and bench. paste a link, press one button, watch the program's own progress rather than a spinner, and get a reveal button on the file at the end.

a second consent card, written like the first one. the tab does nothing until it is answered. it shows the two addresses it would fetch from rather than a sentence promising they are harmless, the same way the update card shows its own request. say never and it is off and does not ask again. the switch to turn it back on is in settings under ?.

two helper programs, fetched once and kept outside keeper. yt-dlp and spotDL go into bin beside the seat file, not into the install, so a keeper update never throws them away and never has to fetch them again. yt-dlp's bytes are checked against the sha256 its project publishes. spotDL publishes no checksum, so it is verified by running it, and the difference is reported rather than glossed: a claim about a checksum nobody computed is worth less than no claim at all.

spotDL matches, yt-dlp downloads. spotdl download does not work: spotDL 4.5.2 carries a frozen copy of yt-dlp, youtube refuses that copy, and every track fails while still exiting zero. so spotify links are resolved by spotDL to the track they stand for and fetched by keeper's own yt-dlp, which is the half that has to stay current. one downloader, and it is the one keeper keeps up to date.

ffmpeg is found by looking, not by hoping. a mac app launched from its icon gets PATH=/usr/bin:/bin:/usr/sbin:/sbin, which does not have homebrew on it, so the ffmpeg somebody definitely installed was invisible: yt-dlp pulled a whole stream down and then failed to convert it, leaving a webm where an mp3 was asked for. keeper now finds ffmpeg by absolute path, hands the location to yt-dlp, and says so on the form before a link is pasted if it cannot find one anywhere.

what got more expensive

the update payload went from 0.36 mb to 0.40 mb, which is the two new modules and nothing else. no new dependency, so an installed keeper can still swap source files instead of downloading a runtime it already has.

the readme's oldest promise needed rewording. it said one thing here can reach the internet. it now says two, and says which. the wifi test it invites you to run still passes for the shelf, the bench, the tags, the crops and the exports.

a spotify link takes about a minute, most of it spotDL working out which track you mean. a youtube link is about twenty seconds. both measured on a link to a ten minute video.

what we still do not have

none of this has run on windows. not the new tab, not the binary fetch, not the paths. the code names yt-dlp.exe and spotdl.exe and looks in the winget, scoop, chocolatey and program files folders for ffmpeg, and that is reasoning rather than a test. the same caveat has been on every keeper release so far and it is still true.

there is no way to stop a download once it starts. close the tab and it carries on until it finishes.

one track a link. an album or a playlist link is turned down with a note saying so, rather than quietly downloading the first track of eighteen.

ffmpeg still has to be on the machine already. keeper fetches the two downloaders and will not fetch a third thing that large. without it the tab says so and does nothing.

a track spotDL cannot find on youtube cannot be downloaded, because youtube is the only place the audio is actually coming from.

keeper 0.6.3

export stops doubling. exporting a tray into a folder you had already
exported it to wrote a second copy of nearly every frame under a suffixed
name. two thousand frames became four thousand on the second press, and the
line at the end said "2001 aliased", which was true and useless. a re-export
now says "0 written, 2002 already there" and the folder does not move.

telling one photograph from another is done by size and then by bytes. two
scans of one negative come off a scanner under the same name at the same
length, and comparing the size alone read those as one photograph, so the
second tray exported into that folder wrote nothing and called it done.

export stops abandoning the rest. one photograph the drive would not read
threw out of the whole run, leaving a folder that looked finished and was
not, and the retry doubled whatever had landed. each frame now fails on its
own and says why in words.

the alias export had a ceiling at 8079 frames. it is chunked.

anything you can drag onto the window leaves the window usable. a pdf, a text
file, a single photograph, a folder alias, an empty drop: one plain sentence
each, and a real folder dropped straight afterwards still opens.

the walkthrough turns up on a first launch. a launch with an update to offer
put the card in front of it and wrote the seen flag anyway, so the one run it
was meant to appear on was the run it was lost on. eight cards down to seven,
and the two that pointed at nothing are anchored or gone.

keeper 0.6.2

Nothing you already have stops working, and there is nothing to migrate.

This one is about the seam where the folder changes under keeper: opening
another one, renaming one, or deleting out of one. Everything below was found
by going looking, not by anybody hitting it, and every number was measured on
this machine twice, once against 0.6.1 and once after.

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

	0.6.1	0.6.2
open another folder a second after a bulk keep	240 tag writes left the first archive holding 1 row of 30, and put 30 of its ids into the second	all 30 stay where they were meant to go
the same, on the bin	2 of 200 survived	200 of 200
a delete queued when you switch, on two copies of one shoot	the archive nobody touched had its index emptied and its bin destroyed	it is not touched
delete when keeper cannot read the file	trashed 1, the photograph still on the drive, the frame gone from the index and the bin	the frame stays, and it says so
rename a folder inside your archive	every star, tag, bin entry, placement and tray membership under it, gone, silently	carried across
a case only rename	the same folder to the drive, a different one to keeper	carried across
adding photographs to an open folder	they never appear	look again
a rescan from the window at all	there was none, at all	look again, under the folder name
clips, from the app icon, after you install ffmpeg	no poster, no reason given, while a terminal worked	found
the first finder prompt on a clean mac	keeper wants to control finder	a sentence saying which three things and why
automated tests	42	59

the rename, and what it will not do

A frame's identity is a hash of its path inside the archive. That is what lets
a folder grow without every decision sliding onto the wrong photograph, and it
is not changing. What it cost is that a rename made every id underneath new.

A rescan now reconciles. A frame that left the index is matched to a frame that
arrived when they are the same file name at the same byte count, and only when
both halves are unambiguous. It will not match on a name alone, because two
shoots off one card hold the same names. It will not choose between two
candidates, because there is no honest way to say which of them your star
belonged to. It will not carry onto a frame that already decided something for
itself. When it cannot be sure, it does nothing, and your decision is still on
the disk where it was.

what is still open

• Dropping a file that is not a folder onto the window opens the folder chooser
  behind it, and there is no way back except a reload.
• Twenty thousand frames scrolls at fourteen frames a second. Two thousand
  scrolls at a hundred and forty. There is no virtualisation.
• Two of the eight walkthrough cards point at something you cannot see, and the
  walkthrough does not appear at all if an update is waiting.
• If sharp will not load on your machine, doctor cannot run to tell you so.
• A tray export killed part way leaves one truncated photograph, and running it
  again writes the good copy under a different name and leaves the broken one
  under the natural one.
• Exporting a tray twice into the same folder duplicates every photograph and
  reports it as work done.
• "out": "~/Desktop/crops" in a config makes a folder literally called ~.
• Nothing has ever run on windows. It is still not notarised.

keeper 0.6.1

Nothing you already have stops working, and there is nothing to migrate.
An archive culled with 0.6.0 opens in 0.6.1 and keeps its tags, its bin and
its placements.

One thing is worth doing by hand: if your archive holds heic or tiff, run it
once with --rescan. Those two never decoded before, so there is nothing on
disk for them 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

This started as two black squares in a shelf and a quick look card that opened
onto nothing. Both are fixed. Then five sweeps went looking for what else was
under them, and the worst thing they found was not either screenshot.

	0.6.0	0.6.1
a thumbnail cut off by a kill mid scan	black for the life of that folder, and no rescan ever repaired it	rebuilt on the next scan
that same empty file, served	200, and a blank tile	404
a tile with no thumbnail	the browser's broken picture glyph, and no word	one retry, then no preview and the reason
a photograph moved in the finder while keeper is open	a black card with the size and the path floating in it	that file is not where keeper left it
a file that is there and cannot be drawn	the same black card	its own sentence, because it is a different problem
every photograph off an iphone	a black tile reading unreadable	drawn, and it opens
a tiff	the tile looked right and the frame would not open	drawn, and it opens
select all, press one tag key, 2,200 frames	834 of the 2,200 thrown away, undo empty, the wall saying they all landed	one request, all 2,200 on the disk
the same key on 20,000 frames	the tab pinned a core and never came back	20,000 rows on the disk in one second
a write that could not be sent at all	an unhandled error, no rollback, no undo	rolled back, and the corner says so
a decoder that wedges on a damaged file	held the whole scan for 521 seconds	gives up at 120, like every other call
duplicating an archive in the finder	the copy was refused, pointing at a window showing another folder	it opens
cancelling the folder chooser	an applescript error, at somebody who changed their mind	nothing
automated tests	27	42

Every number there was measured on this machine, twice: once against 0.6.0 to
see the fault, once after to see it gone. Ten of the fourteen new tests fail
against the code they replace.

What it costs. A relaunch on a folder keeper has already scanned pays
about half a second more at twenty thousand frames, 2.4 seconds against 2.9,
because it now reads twelve bytes of every thumbnail instead of asking whether
a file is there. At two thousand it is 291 milliseconds against 306. That is
the price of never again having a tile that is blank for good.

what is still open

Said plainly, because five people are about to use this.

• Opening a second folder while a bulk keep is still being written puts the
  writes into the wrong archive. There is a one to three second window after
  select all and a keystroke. On two copies of one shoot it emptied the
  untouched one's index. Do not switch folders straight after a bulk action.
• Delete reports success when it cannot read the file. A folder whose
  permissions changed under it drops the frame from the index while the
  photograph stays on the drive.
• Renaming a folder inside your archive loses every star under it. A
  frame's identity is its path, and nothing reconciles the old one.
• There is no way to rescan from the window. It is --rescan on the
  command line or nothing, which also means a photograph added to an open
  folder never appears.
• Dropping a file that is not a folder onto the window opens the folder
  chooser behind it and there is no way back except a reload.
• Twenty thousand frames scrolls at fourteen frames a second. Two thousand
  scrolls at a hundred and forty. There is no virtualisation.
• Two of the eight walkthrough cards point at something you cannot see, and
  the walkthrough does not appear at all if an update is waiting.
• If sharp will not load on your machine, doctor cannot run to tell you so.
• Opened from its icon the app cannot see ffmpeg, so clips have no poster
  frame even after you install it.
• Nothing has ever run on windows. It is still not notarised.

keeper 0.6.0

Nothing you already have stops working, and there is nothing to migrate.
An archive culled with 0.5.1 opens in 0.6.0 and keeps its tags, its bin and
its placements. keeper writes one new file beside them, run.json, which says
which keeper has the folder open, and one .json.bak next to each sidecar,
which is the copy it falls back on.

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

This is the release that stops keeper losing your work. Everything else in it
is downstream of that.

	0.5.1	0.6.0
automated tests	0	27
a write killed mid flight	tags.json left at 6,291,456 bytes, unparseable, and the page then said 0 tags with no error	11 bytes, parses, still holds the old value
the same write on a full disk	2,621,440 bytes, unparseable	refused, file untouched
two keepers on one archive	78 of 80 stars gone, every response 200	the second is refused, and the sentence names the port the first is on
keeper tag run beside the page	80 rows became 3, every tag letter gone	every row and every star survives
a star you set, on a frame an agent's sheet covers	wiped, and the terminal said tagged 4 frames	kept
a website you are visiting posting to keeper	accepted	403, on the origin and on a per launch token
export when you deleted the sidecar	the jpeg was silently replaced, and it said wrote 1 crop	steps to a new name
two exports at once	both picked the same name, one file survived	the disk decides, the loser steps on
crops written inside the archive	the next scan indexed them as new frames	refused, with the reason
icon launch on a cold folder	nothing here yet, still blank nine seconds after the scan finished	the scan is on screen, then the shelf
your second ever launch	new in this keeper, you have probably worked most of it out already	the eight walkthrough cards, once
a folder keeper cannot write	EACCES: permission denied, mkdir	a sentence
the object-position css on the bench	only if you had written a keeper.config.json, so nobody ever saw it	always, with a copy button
the zoom readout on a fresh crop at cover	67%	100%
shelf and tray at 800x600	the page scrolled, 675 into 600	no overflow
the shortcuts sheet at 800x600	its tabs and close button at y = -43, above the top of the window	reachable
keycaps in that sheet	two rows overran their box by 11px, at every size	none
brand rules broken	5	0
keys with no route in the interface	7	0
what borders the quick look picture	warm chrome, rgb(29,25,21)	rgb(0,0,0)
the filter chips at 800 wide	474px tall, chrome eating 434 of 600 before a photograph	a sidebar that scrolls
the icon, when the remembered folder went read only	bounces, spins for 20 seconds, quits. no window, no sentence, for ever	the empty page, and the reason in the log
the folder chooser	never came to the front, while the page said it had	comes forward
the first seconds of a cold scan	the progress bar and "found no photographs" drawn on top of each other	the scan alone
a folder renamed or unplugged while open	900 broken image icons and no word	a sentence naming the folder
the privacy notice in the dmg	a hidden dot file	visible

what we did not have, and now do

Your archive survives being interrupted. Every write went straight over
the file it was replacing, so a keeper killed at the wrong moment left an
unreadable tags.json, and the next launch read that as no tags at all and
made it permanent. Writes now go to a temp file, get flushed to the disk,
and are renamed into place, which the filesystem does in one step, and the
previous copy is kept beside it. A file keeper cannot read now stops the
archive at the door and tells you which backup to look at, instead of quietly
starting again from nothing.

One keeper per folder. There was nothing stopping two, and two of them
silently overwrote each other's work: measured, 78 of 80 stars gone with every
request answering 200. A keeper now claims the folder while it holds it, and
a second one tells you where the first is instead of joining in. A claim left
behind by a crash is swept, and a claim whose port does not answer is not
believed, so a .keeper folder that travelled with your photographs to
another machine cannot lock you out.

keeper is no longer reachable from the web page you happen to have open.
Any site could post to it and have your photographs copied somewhere it chose
the name of. Every request that changes anything is now checked twice, on
where it came from and on a token minted for that launch, and neither is
something another page can get hold of.

The bench finally shows you the thing it is for. The line of css that
reproduces your crop was behind a config file, so anybody who had not written
one had never seen it, which is why the board is the least used screen in the
app. It is always on screen now, there is a button that copies it, and every
export writes a .css beside the crop with a rule you can paste.

The first minute makes sense. Opening from the icon showed an empty shelf
that never filled in, because nothing on the page asked whether a scan was
running. It shows the scan now, then the shelf. The walkthrough runs for
somebody who has never seen keeper rather than on their second launch. No
screen tells you to run a command that is not on your PATH.

It looks like a mac app. The wall of filter chips is a source list on the
left that scrolls on its own, the top is a real toolbar that does not wrap,
and the photographs get the rest of the window. Two zones still hold: nothing
warm touches a photograph anywhere, and the quick look is pure black on all
four sides of the picture at every size.

There are tests. 27 of them, node --test test/, no new dependency. Six
reproduce a way keeper used to lose work, and each of those six was confirmed
to fail against the old code, which is the half that usually gets skipped.

what got more expensive

Every write costs more, and the cost is a real one. Flushing to the disk
and keeping a backup is three operations where there was one:

tags.json	before	after
100 rows, 4 kB	0.12 ms	4.02 ms	33x
8,000 rows, 327 kB	1.52 ms	6.06 ms	4x
60,000 rows, 2.5 MB	9.78 ms	16.41 ms	1.7x

Most of that is a fixed cost, the flush, which is why the smallest write looks
worst and the largest barely moves. At the size a real archive reaches it is
about six milliseconds, against a file that used to be destroyed outright by a
badly timed ctrl c. It is the right trade and it is not free.

Your sidecars take twice the disk, because each one now keeps its last
good copy beside it. On a 2.5 MB tags.json that is 2.5 MB.

Opening a folder costs a little more. A claim file is written, and when
one is already there, a request to the port it names with half a second to
answer before it is treated as gone.

what we still do not have

Nothing in this release ran on windows. 527 lines of platform code have
still never been executed there, and the two known windows defects, the drop
panel and photographs not loading, are still reasoned about from a mac rather
than reproduced. One concrete mechanism was found for the second and the
parsing was fixed, unverified.

It is still not notarised. Your mac still says the developer cannot be
verified, and the two curl lines above are still the way around it. The
signing is ad hoc, Gatekeeper rejects the app, and the bundled node carries an
entitlement Apple rejects outright, so this is more than a certificate away.

No test touches the browser. The 27 are the server, the store, the claim
and the crops. The interface was verified by driving a real browser by hand
at seven window sizes, which is not the same as something that runs on its own.

Two known faults are still open, both cosmetic. Trashing a photograph you
had already moved yourself reports it as trashed, which is the wrong sentence
for the right outcome. And a keeper killed in the middle of writing a crop
leaves a zero byte file behind, which nothing tidies up.

Three rough edges in the new sidebar, named rather than hidden. The only
filters sit below its fold on a short window. Below 900 pixels wide with the
tray open the sidebar hides itself, so the key that opens it appears to do
nothing. And at 800 pixels the counts lose their words and read as three bare
numbers, because that is all the room there is.

Why keeper reads your Desktop and Downloads without asking was not
established. It may be a permission this machine already granted, or it may be
that a background process gets a quieter pass. A genuinely first ever launch on
a clean mac may put a dialog up that nobody here has seen.

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.

keeper 0.5.0

keeper 0.5.0

nothing about your archives changes. an existing .keeper folder is read and
written exactly as 0.4.3 left it, tags, placements and trays included, and
0.4.3 can open a folder 0.5.0 has touched. an installed keeper can update
itself to this one from inside its own window.

on a mac, two lines and no warning:

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.0-windows-x64-setup.exe and open keeper from
the start menu.

against 0.4.3

	0.4.3	0.5.0
what a new machine gets	one sentence along the bottom	eight cards over your own archive
what an existing keeper gets on update	nothing	one card, two buttons, no thanks or show me
where the answer is remembered	the browser, and a browser remembers it per port	keeper's own file, once per machine
settings you can change later	the click sound	the click sound, auto advance, whether keeper may look at github, and the walkthrough again
where the settings live	one button in the shortcuts sheet	a second pane behind the same ?
ways onto a mac	the disk image	the disk image, or a tarball and two lines
what the mac warns you	the developer cannot be verified	nothing, if you used the two lines
mac download	51 mb disk image	52 mb disk image, 47 mb tarball
windows installer	31 mb	31 mb
the page itself	433 kb of js, css and html	456 kb
shortcuts	30 rows on one sheet	30 rows on one sheet
what leaves your machine	nothing you did not ask for	nothing you did not ask for

what we did not have, and now do

a first run that shows the keyboard instead of mentioning it. 0.4.3 put one
sentence along the bottom of the screen saying that letters tag and ? has the
rest. that sentence was true and it was not enough. keeper's whole argument is
that a thousand frames is twenty minutes with one hand, and somebody who has
not read the readme sits down, sees tiles, and clicks, because clicking is what
an unlabelled page teaches. eight cards now walk the room in the order the day
happens in: look, keep, tag, set aside, pile up, cut to shape. the app stays
live underneath them and nothing is blocked, so every key a card names can be
pressed the moment it is named, and pressing it moves the card on.

and it asks first if you already use keeper. a machine that has never run
keeper gets the cards, because a first run has nothing to interrupt and a wall
of unlabelled tiles is the whole problem. a machine that has run keeper before
gets one card with two buttons instead. updating and being immediately taught
your own tool is a bad way to be thanked for updating, and no is an answer that
is written down. keeper works out which one you are from what its own file said
before this launch touched it, so a first run and a hundredth cannot be
confused five seconds in.

the answer records which walkthrough you saw and not merely that you saw one, so
a later keeper with something genuinely new to show can ask once more. it will
not fire on a fix or on a version number moving: the number only goes up when
the cards do.

a settings pane, on the key people already press. the sound switch used to
be the only preference keeper had a home for. auto advance lived in the bar,
and whether keeper may check github could be answered exactly once, on a card
that never came back, so anybody who changed their mind had nowhere to go. all
four are one pane now, behind the same ? as the shortcuts, each written as
what it does to your machine rather than as its own name.

the walkthrough is remembered per machine and not per browser tab. the old
one wrote its bit into the browser's storage, and a browser keys storage to an
origin, and keeper's origin carries a port. keeper app takes the first free
port from 7777 upwards, so opening keeper on a day when something else held
7777 handed you a different origin with an empty store and started the first
run again. it is one line in the same file keeper already uses to remember
which archive you had open.

a mac install that never meets gatekeeper. this is the one worth reading if
you gave up on keeper before. a disk image a browser downloaded is quarantined,
macos carries that mark into the app inside it, and the first open of an app
carrying it that nobody has paid apple to notarise is refused. there is a way
through and it is four clicks deep in system settings, past a sentence saying
the developer cannot be verified, which is where most people stop. curl
writes no such mark, because a file you fetched with a command you typed is
treated as something you chose. so the same app, the same ad hoc signature, the
same bytes, also ships as a plain tarball, and the two lines at the top of this
note are the install that works today. the disk image is still there and still
works, and it still argues with you once.

a written list of what keeper is being pointed at. film cropped and trimmed
the way the photographs already are, more inside the crop than one per shape, a
size for youtube, and an export that goes where it is going instead of into a
folder you then open somewhere else. it is in the readme under "what is
coming", with no dates on it, so you can tell whether the thing you need is on
the list or not on it at all.

what got more expensive

the page carries 23 kb more javascript and css, 433 to 456. it is served off
a socket on your own machine, so this is a number rather than a wait, but it is
23 kb that did not exist.

return is taken off the shelf while the walkthrough is up. a card with a
primary button answers to return, and it has to win against the shelf, which
answers a bare return by opening the quick look. it costs nothing, because
return on the shelf is the second way to do what space does and space is the
key the card in front of you is naming, but for those eight cards it is a key
the app no longer answers.

each mac release is about 100 mb bigger, because the tarball is a second
copy of the same app per architecture. that is the price of the two lines.

what we still do not have

no signature and no notarisation. the two lines above walk around a warning.
they are not a substitute for the money that would remove it, and they do not
make anything about this build more trustworthy than it was. the reasons to
trust it are unchanged: every line is in this repository, the downloads are
built by a workflow you can read, and every file has a checksum beside it.

nothing in this release has been run on real windows. the walkthrough and
the settings are the same code on both machines and the keys are named in the
words a pc keyboard uses, which was checked by making the page believe it was
on one. that is not the same as a windows laptop having opened it.

the walkthrough does not know what you already know. it is eight cards in
one order for everybody, and somebody who has used a culling tool before sits
through the same cards as somebody who has not. skip is one press and it is
remembered.

there is still nothing for film past the poster frame. keeper reads mov,
mp4, mkv and the rest and shows you a frame from each, and the bench crops
stills only.

keeper 0.4.3

keeper was walking into your photos library and putting its insides on the
wall. that is the one to read. the other three are keeper knowing something
and not saying it.

updating to this is one click from any 0.3.x or 0.4.x: press the version in
the header.

mac	open the .dmg, drag keeper to applications, open it
windows	run the .exe setup, then open keeper from the start menu

0.4.2 against 0.4.3

	0.4.2	0.4.3
a photos library inside the folder you opened	walked into, and its derivatives put on the wall	left closed, and said so
a lightroom preview cache	every frame appeared twice	left closed, and said so
a frame the decoder cannot open	a blank rectangle, no reason given	says unreadable, with the decoder's words
the size of a portrait frame in the quick look	800x1200 drawn as 800x120	drawn whole, or not at all
pressing k	nothing said back	the card says kept
selecting a clip with no poster	the selection ring vanished	it stays
answering never, then wanting an update	"updates are turned off", no way back	pressing the version installs it

the library one

point keeper at your pictures folder and there is usually a photos library
sitting in it. keeper walked in. on a mac that is a permission prompt you did
not ask for, and then several thousand of that library's internal derivatives
on the wall, presented as photographs you took. a lightroom preview cache did
something quieter and worse: it holds a small copy of every frame already on
the wall, so your archive turned up twice, once as itself and once as
thumbnails of itself.

the rule for this already existed. the half of keeper that finds a folder you
dropped knew a .photoslibrary is a document wearing a folder's clothes and
walked past it. the half that scans had never been told. two lists meaning one
thing, and only one of them was right.

one list now, asked by both, and hidden folders go by rule rather than by
name, because a list of names can only ever hold the caches somebody has
already been bitten by. a library that gets left closed is said out loud
rather than dropped in silence, since it is the one skip that hides
photographs rather than clutter:

2 libraries left closed: Lightroom/Previews.lrdata, Photos Library.photoslibrary
  these are apps' own folders. export from the app to cull what is inside them.

measured on an archive with sixteen frames planted inside a photos library, a
.lrdata cache, a synology @eaDir and a hidden folder. before: all sixteen
were indexed. after: none.

the number that was not true

the quick look put four facts on one row with one ellipsis on it, and an
ellipsis eats the tail of its box without caring what the tail means. on a
portrait frame, the narrowest card keeper draws, it ate back through the
folder name and into the resolution, and 800x1200 was drawn as 800x120.

that is not a shortened number. it is a different number, it is a plausible
one, and it sat exactly where you decide whether a frame can be a 2400px
banner. whole facts are given up now instead, in a set order: the folder
first, since the path underneath spells it out anyway, then the running time,
then the tag. the resolution is the last thing standing, because that card is
the only place it appears.

the door that locked from the inside

answering never to the update question turned off the check, which is right.
it also made the install button unreachable forever, which is not: pressing
the version still found a newer keeper and then refused to fetch it, and the
only control that could have said yes was a card that never appears again.

may keeper look on its own, and may it install the one you are pointing at,
were never the same question. the second is answered by pressing the button.
nothing is written either way, so a keeper you told never stays as quiet next
launch as you asked.

this is not hypothetical. a machine here sat on 0.3.1 through five releases
for exactly this reason, and never received a single one of the windows fixes
shipped in between.

if you already answered never, this release cannot reach you, and there is
no way it could. the fix is in the copy you do not have. measured on a real
0.4.2 install carrying that answer: pressing the version finds 0.4.3 and the
install is still refused. download the setup or the dmg from this page once,
by hand, and it never happens again. everyone else, including anyone who has
not been asked yet, updates by pressing the version.

an update also no longer stages in the system temp folder. every step of the
swap is a rename and a rename cannot cross a volume, so anyone whose TEMP
sits on another drive had an updater that could not install anything and
blamed the swap for it.

smaller

the windows doctor ended in pause, so the one command whose entire purpose
is producing text to send to somebody else could only be run by a hand on a
mouse. it now writes its report to %LOCALAPPDATA%\keeper\doctor.txt as well
as the window, and only waits for a key when it was opened by double click.