PrintVault Desktop v0.2.28

A print that finishes now takes itself off the queue, and printing the same file twice in one day is finally logged twice.

The queue closes its own rows

The monitor already did the hard part. It notices a job ending, writes the print log with the real duration and the real filament rather than the slicer's estimate, and takes the grams off the spool. It simply had no idea the queue existed. So a row you started, that PrintVault sent, watched and logged entirely by itself, still sat there saying printing until you went and ticked it off.

A successful send now writes onto the row which file went to which printer, and the monitor looks that up when a job ends. What it finds back there is better than anything it could work out alone: the model comes off the row instead of being guessed out of the filename, and the spool you chose when you queued the job wins over whichever one happens to be flagged in use.

A run of six is six prints, so a finished copy advances a count rather than closing the row, and the row drops back to pending ready for the next one. The row, its estimates and the totals across the top all count what is left instead of what you first typed, so a batch half way through reads 4x with "2 of 6 printed" beside it. A print that stops early counts for nothing and goes straight back. Pressing Done yourself still closes the whole row, however many copies were on it.

Printing something twice a day now records both

Making that count work exposed why it never could have. The guard against logging one job twice matched on printer, file and day:

x.auto && x.printer === printer.name && x.date === U.today() && x.jobFile === name

Which quietly meant a file could only be logged once in a day. Print the same thing three times in an evening and you got one print record and one filament deduction. The other two were dropped on the floor, grams and all, and nothing said so. Anyone running repeats, a batch of the same part or a printer farm, has been losing print history to this.

It is a flag now, set when a run is written down and cleared the moment the printer reports printing again. One run logs once, on its own account, however alike two of them look. A window of time was the obvious fix and the wrong one: a short print is genuinely indistinguishable from a duplicate tick that way.

Fixed

• The queue was unusable on a phone. The card is a single nowrap row, so the wider button labels that came with 0.2.27 squeezed the name column to nothing, wrapped its details one word per line, and pushed the last button off the screen. It wraps below 640px now, name beside the thumbnail and the buttons underneath. The printing row had been overflowing on its own since well before those labels.
• The duplicates tab said "N in zips" above a list that has always counted 7z and rar too.

PrintVault Desktop v0.2.27

Start in the queue sends the print now, a cost calculator for a run before you commit to it, and 7z archives read like zips.

Start actually starts something

Reported by @howardaron-git in #4. Pressing Start on a queued item made the row say PRINTING and did nothing else, because that is all the code did: it wrote a word on the record and redrew the screen. Nothing anywhere read that field except the badge you were looking at and the button's own label. In an app that can push gcode to Moonraker and OctoPrint, a button called Start had no business doing only bookkeeping.

Start now opens the same send window the model screen uses, with this item's model already chosen and the printer named on the row already selected. The row is marked as printing once the upload has come back, not the moment you press the button. There was a separate send icon on the row that did roughly this, but it only appeared once you had a printer with a network address saved, so most people never saw it. Start replaces it.

In the browser build there is nothing to send to, so the button says Mark printing and does only that, which was the honest name for it all along.

What is this going to cost

A cost button on a model asks how many copies you want and works out the filament and the running cost for the lot, using the grams and minutes already read out of your sliced gcode. Pick a spool and it says whether there is enough left on it for the whole run, which is the thing you actually want to know before starting a batch at eleven at night.

Everything is editable, so a model with no sliced gcode can still be estimated by typing the numbers in. The hourly running cost is a setting, so it carries over.

7z

The desktop app lists and extracts 7z archives the same way it handles zips: contents indexed and searchable without unpacking, extract when you want the files out. The browser build cannot do this. 7z is LZMA, and a decoder for it would mean adding a dependency to a file that deliberately has none.

The archives view on the Duplicates tab counts them too, so a 7z sitting beside the folder it was already extracted into now shows up as reclaimable rather than being ignored.

Also

• Six accent colours under Settings, on top of the light and dark themes.
• The updater says why it found nothing instead of going quiet, and there is a button to make it look.
• Press ? for the keyboard shortcuts, and the hints name the right modifier key for your platform.

Fixed

• The delete confirmation printed the raw markup of the trash icon across the dialog instead of drawing it.
• Prices ignored the currency setting and always showed a dollar sign.

PrintVault Desktop v0.2.26

Gcode you slice by hand gets picked up on its own, several slicers instead of one, and the app can tell you what changed.

Slice where you like, come back, it is there

Send a model to your slicer, slice it, save the gcode beside the model, and come back to PrintVault. It notices and indexes it, so the file is there with its settings read out and ready to send to a printer, without you remembering to rescan.

It only looks at the one folder you sent from, only when the window comes back to the front, and only once. If nothing turned up it says nothing.

This is deliberately not slicing from inside the app. I tried that first. OrcaSlicer's Windows build is a small launcher for a very large DLL, and handed command line arguments it starts its whole interface and exits without slicing. It also only writes errors to a console it inherits directly, so anything driving it cannot report why it failed. A Slice button would have failed silently exactly when you would use it, with the slicer already open. Watching for the output works with every slicer instead of one, and has nothing to go quietly wrong.

More than one slicer

Settings held a single slicer path, which is fine until you have Orca and Creality Print installed, or a different slicer per printer. It is a list now. Add as many as you like, rename them to whatever you call them, and Send offers a button for each. Your existing setting is carried over.

What changed, in the app

The version number in the header opens a short list of what is new, and the same list appears once by itself after an update. It is in the file rather than fetched, so it works offline like the rest of the app.

Fixed

• Slicer names were taken from the whole file path rather than the file name on Windows, because the path helper only splits on forward slashes and a file picker returns backslashes.

PrintVault Desktop v0.2.25

Removing files is reversible now, and a scan can no longer wipe your index.

Your index survives a folder going missing

If the browser lost its handle on a folder, which cloud sync clients like OneDrive cause routinely by replacing a directory, the scan saw an empty folder, decided every file had been deleted, and stripped the whole index: tags, notes, collections, and the links print history hangs off. The files on disk were always fine, but everything you had typed about them was not.

A scan now stops the moment the top level fails to list, and says the connection was lost and that adding the folder again reconnects it. A folder that has genuinely been emptied still prunes as before.

This one predates the release it is fixed in by some months. If your library has ever looked thin after a sync, this is likely why.

Quarantine has a way back

Removing a duplicate or deleting a model moves files to _PrintVault_quarantine rather than destroying them, and the scanner skips that folder. Until now there was no way to get anything out of it without opening a file manager.

Settings now has Show what is in quarantine, which lists everything in there with the path it came from. Put one back, or all of them. A restore refuses to write over anything that has taken the old path in the meantime, and emptying the folder asks you to type it out, because by then it really is the last copy.

Deleting a whole model

You no longer have to remove files one at a time. The model view has a Delete that takes the lot, honours the quarantine setting, and tells you how many files and how much space before you commit.

Permanently deleting three or more files, or ten in duplicate cleanup, now asks you to type DELETE. Moving to quarantine deliberately does not, because making the recoverable path as annoying as the unrecoverable one only teaches people to turn the safety off.

A less cluttered model screen

The footer had grown to nine buttons and stood four rows tall on a phone. It is five now, with the rest behind More, and Delete no longer sits one slip away from Log print. File rows went the same way and no longer scroll sideways on a phone.

Smaller things

• Show in folder, for a single file or the whole model, on desktop.
• Arrow keys move around the library grid, Enter opens, Home and End jump to the ends.
• The removal setting is relabelled and now says it governs both duplicate cleanup and deleting a model.

PrintVault Desktop v0.2.23

Open in slicer finally works on macOS, and you can delete a whole model.

Open in slicer

Picking any application on macOS gave "Permission denied (os error 13)", which reads like a sandbox or code signing problem and is neither. A macOS application is a bundle, which is a directory rather than something you can execute, so running it directly fails. Application bundles go through Launch Services now, while a plain command line binary still runs directly.

Found, diagnosed and tested on real hardware by @howardaron-git, who also sent the fix. macOS is the platform I cannot test, so this sat there quietly until somebody who could actually run it went looking. See #3.

Deleting a model

Removing a model meant opening it and deleting each file one at a time, which for a forty file pack is not really a feature. There is a Delete on the model now that takes the lot.

It follows the duplicate cleanup rather than the single file delete, so by default it moves everything to the quarantine folder instead of destroying it, and tells you how many files and how much space before you commit. The emptied folder is removed too, but only if it is genuinely empty.

PrintVault Desktop v0.2.22

Share models straight to the macOS share sheet.

Asked for by @howardaron-git, who kept being sent "can you send me that thing you printed" by family with their own printers, and was digging through folders in Finder to answer.

There is a Share button in the model view, and one on the selection bar, so you can cmd-click two or three models and share the lot. It hands the files to the normal macOS sheet, so AirDrop, Messages, Mail and anything else you have in there. Sharing a model means its printable files, or the archive if it is a zip you never unpacked.

macOS only. Windows has an equivalent but only through a much uglier interface, and Linux has no standard one, so the button is simply absent elsewhere rather than there and disappointing.

Large files go through AirDrop or a transfer service happily. Mail and Messages have their own size limits and will not.

Written without a Mac to test on, so thanks to @howardaron-git for checking it worked before it shipped. See #3.

PrintVault Desktop v0.2.21

The sidebar no longer traps itself open on a phone.

Below 900px the sidebar stops being a column and becomes an overlay on top of the content, covering most of a phone screen. There was no way to dismiss it: the toggle button carried an inline style that hid it, its CSS class did not exist, and the function behind it was never called from anything. On the library tab it simply sat there, and a first visit had the "Choose a folder" button buried underneath it.

The button now appears and works at that width, tapping away from the sidebar closes it, and choosing a filter closes it too rather than leaving it over the results you just asked for. Whether it is open is tracked separately from the desktop setting, so a phone visit no longer decides what your desktop does.

Only affects narrow windows. On a desktop it is the same column it always was.

PrintVault Desktop v0.2.20

A demo you can click around before pointing it at your own files.

Adding ?demo to the app URL fills it with an invented library: models, prints, spools, a queue and a few duplicates, so you can see what the thing actually does without handing it a folder first.

It is generated when the page loads rather than shipped, and the previews are real WebGL renders of meshes built in code, so it adds nothing to download. It runs entirely in memory and cannot see or change a real library in the same browser. Close the tab and it is gone.

Try it at https://printvault.magikh0e.pl/app/?demo

PrintVault Desktop v0.2.19

Modifiers stop showing up as blocks in the 3D view.

A slicer project can carry geometry that never gets printed: modifier volumes that change settings inside a region, negative parts, support blockers and enforcers. They were being drawn like anything else, so a model appeared surrounded by large cubes and shrunk into a corner, while its card looked perfectly normal because that picture comes from the slicer's own render.

Anything not marked as a normal part is left out now. On a real file that removed three twelve faced cubes and pulled the bounding box in from 124 x 124 x 48 mm to 117 x 109 x 34, which is the model on its own. The smaller box matters as much as the missing blocks, since the framing is worked out from it: the model fills the view instead of being sized to fit something that was never going to print.

PrintVault Desktop v0.2.18

A fix for the 3D view, worth taking if you picked up 0.2.17.

Opening Send from the viewer and then going back left an empty box where the model had been, and Reset view looked broken from that point on.

Both were the same fault. The viewer draws into a single shared canvas, and restoring a dialog put back an inert copy of it, so the model appeared to vanish and every repaint after that went somewhere off screen. Reset view had been working the whole time, there was just nothing to see.

The bug was not new in 0.2.17, it had simply never come up: any dialog opened on top of the viewer would have done it, and Send is the first one that ever gets opened from in there.