v0.63.11
Point release over v0.63.10: the current stable plus 2 applied commit(s), isolated from the changes still soaking on main.
Patch Changes
-
Filing a bug no longer destroys the thing you were trying to report. In the desktop app, press Cmd+Shift+D (Ctrl+Shift+D on Windows and Linux) and the report opens straight away, without you having to move the mouse or hunt through a menu. That matters more than the convenience: a lot of what goes wrong in an app only exists for a moment. A dropdown showing the wrong item, a hover state on the wrong row, a toast with a confusing message. Reaching the Help menu made all of it disappear before the screenshot was taken, so the picture attached to your report showed the app after the problem had already gone.
Two changes behind the shortcut are what make it actually work. The screenshot is now taken at the instant you press the keys, rather than waiting for menus and tooltips to fade out first, so whatever was on screen is what gets captured. And because a screenshot never includes the mouse cursor, a marker is now drawn at the pointer's last position, so a report about a hovered row shows which row you were pointing at instead of leaving the reader to guess.
Filing from the Help menu gets the same treatment, and so does the Report this error button on a crash screen: they no longer wait either, and they draw the same pointer marker. Opening the report from the command palette, the Help popover, or the Windows and Linux menu bar still waits for that menu to close first, which is the reason the delay existed in the first place, and those reports carry no pointer marker because the row it would mark has already gone.
-
Clicking an outline row that sits above where you are reading now moves you there, instead of doing nothing for the first ten seconds after a document opens. A freshly opened document keeps a loop running that puts you back where you left off, and that loop only recognized someone else taking the scroller when the page moved down. A click aimed up the document looked like drift to it, so it put the page back, frame after frame, until the loop gave up ten seconds later. The click was never lost; it was being undone. Every explicit navigation now stands that loop down while it lands, so the same fix covers outline rows in both editing modes, Problems rows, raw-MDX jumps, deep links, and find/replace matches.
One behavior worth knowing, because it is new: for about half a second after a jump, other things that scroll the page hold off — the view following an agent's writes, the pull to the bottom of the document while the composer resizes, and revealing the caret as you type. The place you just asked for outranks all of them. Following a link straight to a heading holds a little longer, because it re-aims a few times while the page settles. While you are stepping through find results, or while a linked comment settles into place, the hold-off lasts as long as that does. Reopening a document you had jumped in still returns you to where the jump left you.
Downloads
| Platform | Architecture | Download |
|---|---|---|
| macOS | Apple Silicon | OpenKnowledge-arm64.dmg |
| Windows | x64 | OpenKnowledge-Setup-x64.exe |
| Windows | arm64 | OpenKnowledge-Setup-arm64.exe |
| Debian / Ubuntu | x64 | OpenKnowledge-amd64.deb |
| Debian / Ubuntu | arm64 | OpenKnowledge-arm64.deb |
| Fedora / RHEL | x64 | OpenKnowledge-x86_64.rpm |
| Fedora / RHEL | arm64 | OpenKnowledge-aarch64.rpm |