anki/ts/reviewer/index.ts

264 lines
7.4 KiB
TypeScript
Raw Normal View History

// Copyright: Ankitects Pty Ltd and contributors
// License: GNU AGPL, version 3 or later; http://www.gnu.org/licenses/agpl.html
2021-07-13 00:23:46 +02:00
/* eslint
2021-07-16 17:28:31 +02:00
@typescript-eslint/no-explicit-any: "off",
2021-07-13 00:23:46 +02:00
*/
import "css-browser-selector/css_browser_selector.min";
2021-07-29 15:18:51 +02:00
export { default as $, default as jQuery } from "jquery/dist/jquery";
Various changes to I/O handling (#2513) * Store coordinates as ratios of full size * Use single definition for cappedCanvasSize() * Move I/O review code into ts/image-occlusion A bit simpler when it's all in one place. * Reduce number precision, and round to whole pixels >>> n=10000 >>> for i in range(1, int(n)): assert i == round(float("%0.4f" % (i/n))*n) * Minor typing tweak So, it turns out that typing is mostly broken in ts/image-occlusion. We're importing from fabric which is a js file without types, so types like fabric.Canvas are resolving to any. I first tried switching to `@types/fabric`, which introduced a slew of typing errors. Wasted a few hours trying to address them, before deciding to give up on it, since the types were not complete. Then found fabric has a 6.0 beta that introduces typing, and spent some time with that, but ran into some new issues as it still seems to be a work in progress. I think we're probably best off waiting until it's out and stabilized before sinking more effort into this. * Refactor (de)serialization of occlusions To make the code easier to follow/maintain, cloze deletions are now decoded/ encoded into simple data classes, which can then be converted to Fabric objects and back. The data objects handle converting from absolute/normal positions, and producing values suitable for writing to text (eg truncated floats). Various other changes: - Polygon points are now stored as 'x,y x2,y2 ...' instead of JSON in cloze divs, as that makes the handling consistent with reading from cloze deletion text. - Fixed the reviewer not showing updated placement when a polygon was moved. - Disabled rotation controls in the editor, since we don't support rotation during review. - Renamed hideInactive to occludeInactive, as it wasn't clear whether the former meant to hide the occlusions, or keep them (hiding the content). It's stored as 'oi=1' in the cloze text. * Increase canvas size limit, and double pixels when required. * Size canvas based on container size This results in sharper masks when the intrinsic image size is smaller than the container, and more legible ones when the container is smaller than the intrinsic image size. By using the container instead of the viewport, we account for margins, and when the pixel ratio is 1x, the canvas size and container size should match. * Disable zoom animation on editor load * Default to rectangle when adding new occlusions * Allow users to add/update notes directly from mask editing page * The mask editor needs to work with css pixels, not actual pixels The canvas and image were being scaled too large, which impacted performance.
2023-05-31 05:45:12 +02:00
import { setupImageCloze } from "../image-occlusion/review";
import { mutateNextCardStates } from "./answering";
globalThis.anki = globalThis.anki || {};
globalThis.anki.mutateNextCardStates = mutateNextCardStates;
Feature image occlusion (#2367) * add note types with occlusions and image fields * generate image occlusion cloze div data - generate div element with data-* atrributes for canvas shape generate for reviewer * getting image data & deck id and adding notes the implementation added into backend - added service index in backend.proto for image occlusion request - created image_occlusion.proto with required message and service - implementation in backend for getting image and adding notes, also during editing return imagecloze note and update notes - add notes to selected deck, if no notetype then add image occlusion notetypes - reuse notetype from stock notetypes when not exist * script for generating shapes using canvas api in reviewer - the flash issues fixed by loading image and using image size to draw canvas, also when image get resized, calculate scale using natural width and canvas width to draw shape at right position - limit size of canvas for safari * init image occlusion page in ts and build page with - fabricjs for editing shapes - panzoom for drag and zoom - pickr for color picker - build page using web.rs * implement top toolbar for canvas shapes - undo & redo tools - zoom in, zoom out and zoom fit - group & ungroup - copy & paste - set transparency of shapes - align tools * implement side toolbar for drawing shapes add top toolbar and the side toolbar contains following tools - cursor for selecting shapes - zoom for drag and zoom shapes in mask editor - rectangle for creating it - ellipse for creating it - polygon for creating it using points - shape fill color - question mask color (currently only single color can be added for all shapes) * add maskeditor page for editing mask - add side toolbar and sidebar include toptoolbar - load maskeditor in two mode - for adding note using path to image - for editing note using note id * implement note editor page for adding notes - the note editor page have simple button (B/I/U) and option to toggle html view - option to select deck for adding notes into that deck - option to generate to hide all, guess one & hide one, guess one notes * add image occlusion page add side toolbar, top toolbar, mask editor and note editor - option to switch between mask editor and note editor * implement generates notes and save notes implemention to show toast components for messages * removed pickr & implemented color picker component - remove pickr - implemented using html5 canvas - range input for changing color - another range input for opacity changes - hex and rgba value support * rename methods name & rust unwrap safety - change plural names to singular - create respone message in proto and return response with imagecloze note or error if not found with note id - remove image_occlusion from post handler list - rename service name in mediasrv.py - rename methods name for image occlusion in backend and image_occlusion - update frontend also for update functions' names - handle error in frontend mask-editor.ts, when error getting notes then toast message shown to frontend * extract to function & add comments & remove global - extract function in mask-editor.ts to reduce duplicate - remove unused global from css - add comments to store.ts explaining usage - changes id to noteId in lib.ts - add comments for limitSize, becuase of duplicate implementation * remove image_occlusion notetype - remove from stock notetype, stdmodels - add implementation for notetype to image occlusion - add i18n for errors * update smooth scroll, always show cursor tools - change questionmask to qmask - make selectable for shape true in all tools to simplify edits and draw shapes - update image occlusion in reviewer ts to load image properly * add and get notetype else return errors * fix: not showing occlusion * Use a oneof for ImageClozeNoteResponse Makes it clearer that only one of them can be returned * Don't crash if image filename not provided The second unwrap should be ok, as the input is utf8 * Refactor get_image_cloze_note - fixes crash when note doesn't exist - Ok(None) case was not covered - decouples business logic from native error->proto error conversion - no need for original copy - field[x] is more idiomatic than field.get(x).unwrap() - don't need mutable access to fields * Fix crash if image file unreadable + Use our read_file helper for better error context * Add metadata() helper * Fix crash if file metadata can't be read * remove color picker, qmask and shape color - remove strings from ftl - remove color picker component - remove from cloze generation - remove icons for two buttons - use constant color for shapes * update color in reviewer and ftl strings * fix shape position in canvas & add border to shape - rename mask to inactive shape and active shape color - border witdth and border color - change decimal point deserializing string and toFixed(2) - add thin border in mask editor, may be image background was transparent * fix shape position in canvas after modified - do not draw fixed ratio shapes by turn of uniformScaling - fix rectangle width,height - fix ellipse rx,ry,width,height - fix polygon postion and points - draw outside of canvas also * fix border width and color in reviewer canvas - rename variable * refactor cloze div generate and remove angle * fix origin when drawn outside of canvas from right * fix shape at boundry & not include rx,ry rectangle - move shapes at boundry when pointer is outside of canvas - include rx, ry for ellipse only - include points for polygon only * fix lint errors & update image size in editor canvas based on height and width * remove unsupported layerX & layerX for touchscreen - fix shapes at edges * implemented undo redo with canvas state - implemented undo redo using fabric canvas events - polygon is special case and implemented only added and modified event - rectangle and ellipse have object:added, object:modified and object:removed case - change id to undo and redo * remove background image from canvas and used css to put image tag below canvas editor - set image width and height after adding image * fix for polygon points, add br in cloze strings, & toogle masks button - fix shapes at edges - toggle masks button to show/hide masks - hide clozes string, it contains <br> - set height for div container (used 'relative' in css) * refactor top toolbar, add space and border radius - rename cursor tools - add left and right border * fix undo after undo happen, use transparent color in draw mode
2023-03-29 04:33:19 +02:00
globalThis.anki.setupImageCloze = setupImageCloze;
Move away from Bazel (#2202) (for upgrading users, please see the notes at the bottom) Bazel brought a lot of nice things to the table, such as rebuilds based on content changes instead of modification times, caching of build products, detection of incorrect build rules via a sandbox, and so on. Rewriting the build in Bazel was also an opportunity to improve on the Makefile-based build we had prior, which was pretty poor: most dependencies were external or not pinned, and the build graph was poorly defined and mostly serialized. It was not uncommon for fresh checkouts to fail due to floating dependencies, or for things to break when trying to switch to an older commit. For day-to-day development, I think Bazel served us reasonably well - we could generally switch between branches while being confident that builds would be correct and reasonably fast, and not require full rebuilds (except on Windows, where the lack of a sandbox and the TS rules would cause build breakages when TS files were renamed/removed). Bazel achieves that reliability by defining rules for each programming language that define how source files should be turned into outputs. For the rules to work with Bazel's sandboxing approach, they often have to reimplement or partially bypass the standard tools that each programming language provides. The Rust rules call Rust's compiler directly for example, instead of using Cargo, and the Python rules extract each PyPi package into a separate folder that gets added to sys.path. These separate language rules allow proper declaration of inputs and outputs, and offer some advantages such as caching of build products and fine-grained dependency installation. But they also bring some downsides: - The rules don't always support use-cases/platforms that the standard language tools do, meaning they need to be patched to be used. I've had to contribute a number of patches to the Rust, Python and JS rules to unblock various issues. - The dependencies we use with each language sometimes make assumptions that do not hold in Bazel, meaning they either need to be pinned or patched, or the language rules need to be adjusted to accommodate them. I was hopeful that after the initial setup work, things would be relatively smooth-sailing. Unfortunately, that has not proved to be the case. Things frequently broke when dependencies or the language rules were updated, and I began to get frustrated at the amount of Anki development time I was instead spending on build system upkeep. It's now about 2 years since switching to Bazel, and I think it's time to cut losses, and switch to something else that's a better fit. The new build system is based on a small build tool called Ninja, and some custom Rust code in build/. This means that to build Anki, Bazel is no longer required, but Ninja and Rust need to be installed on your system. Python and Node toolchains are automatically downloaded like in Bazel. This new build system should result in faster builds in some cases: - Because we're using cargo to build now, Rust builds are able to take advantage of pipelining and incremental debug builds, which we didn't have with Bazel. It's also easier to override the default linker on Linux/macOS, which can further improve speeds. - External Rust crates are now built with opt=1, which improves performance of debug builds. - Esbuild is now used to transpile TypeScript, instead of invoking the TypeScript compiler. This results in faster builds, by deferring typechecking to test/check time, and by allowing more work to happen in parallel. As an example of the differences, when testing with the mold linker on Linux, adding a new message to tags.proto (which triggers a recompile of the bulk of the Rust and TypeScript code) results in a compile that goes from about 22s on Bazel to about 7s in the new system. With the standard linker, it's about 9s. Some other changes of note: - Our Rust workspace now uses cargo-hakari to ensure all packages agree on available features, preventing unnecessary rebuilds. - pylib/anki is now a PEP420 implicit namespace, avoiding the need to merge source files and generated files into a single folder for running. By telling VSCode about the extra search path, code completion now works with generated files without needing to symlink them into the source folder. - qt/aqt can't use PEP420 as it's difficult to get rid of aqt/__init__.py. Instead, the generated files are now placed in a separate _aqt package that's added to the path. - ts/lib is now exposed as @tslib, so the source code and generated code can be provided under the same namespace without a merging step. - MyPy and PyLint are now invoked once for the entire codebase. - dprint will be used to format TypeScript/json files in the future instead of the slower prettier (currently turned off to avoid causing conflicts). It can automatically defer to prettier when formatting Svelte files. - svelte-check is now used for typechecking our Svelte code, which revealed a few typing issues that went undetected with the old system. - The Jest unit tests now work on Windows as well. If you're upgrading from Bazel, updated usage instructions are in docs/development.md and docs/build.md. A summary of the changes: - please remove node_modules and .bazel - install rustup (https://rustup.rs/) - install rsync if not already installed (on windows, use pacman - see docs/windows.md) - install Ninja (unzip from https://github.com/ninja-build/ninja/releases/tag/v1.11.1 and place on your path, or from your distro/homebrew if it's 1.10+) - update .vscode/settings.json from .vscode.dist
2022-11-27 06:24:20 +01:00
import { bridgeCommand } from "@tslib/bridgecommand";
import { allImagesLoaded, preloadAnswerImages } from "./images";
import { preloadResources } from "./preload";
2021-07-16 16:33:12 +02:00
declare const MathJax: any;
2021-07-05 12:45:44 +02:00
type Callback = () => void | Promise<void>;
export const onUpdateHook: Array<Callback> = [];
export const onShownHook: Array<Callback> = [];
2021-07-12 15:00:36 +02:00
export const ankiPlatform = "desktop";
let typeans: HTMLInputElement | undefined;
export function getTypedAnswer(): string | null {
return typeans?.value ?? null;
}
function _runHook(
hooks: Array<Callback>,
): Promise<PromiseSettledResult<void | Promise<void>>[]> {
2021-07-05 12:45:44 +02:00
const promises: (Promise<void> | void)[] = [];
2021-07-19 01:33:58 +02:00
for (const hook of hooks) {
try {
2021-07-19 01:33:58 +02:00
const result = hook();
promises.push(result);
} catch (error) {
console.log("Hook failed: ", error);
}
2021-07-05 12:45:44 +02:00
}
return Promise.allSettled(promises);
2021-07-05 12:45:44 +02:00
}
2021-07-12 15:00:36 +02:00
let _updatingQueue: Promise<void> = Promise.resolve();
export function _queueAction(action: Callback): void {
2021-07-05 12:45:44 +02:00
_updatingQueue = _updatingQueue.then(action);
}
// Setting innerHTML does not evaluate the contents of script tags, so we need
// to add them again in order to trigger the download/evaluation. Promise resolves
// when download/evaluation has completed.
function replaceScript(oldScript: HTMLScriptElement): Promise<void> {
return new Promise((resolve) => {
const newScript = document.createElement("script");
let mustWaitForNetwork = true;
if (oldScript.src) {
newScript.addEventListener("load", () => resolve());
newScript.addEventListener("error", () => resolve());
} else {
mustWaitForNetwork = false;
}
for (const attribute of oldScript.attributes) {
newScript.setAttribute(attribute.name, attribute.value);
}
newScript.appendChild(document.createTextNode(oldScript.innerHTML));
oldScript.replaceWith(newScript);
if (!mustWaitForNetwork) {
resolve();
}
});
}
async function setInnerHTML(element: Element, html: string): Promise<void> {
2021-07-05 12:45:44 +02:00
for (const oldVideo of element.getElementsByTagName("video")) {
oldVideo.pause();
while (oldVideo.firstChild) {
oldVideo.removeChild(oldVideo.firstChild);
}
oldVideo.load();
}
element.innerHTML = html;
for (const oldScript of element.getElementsByTagName("script")) {
await replaceScript(oldScript);
2021-07-05 12:45:44 +02:00
}
}
Move away from Bazel (#2202) (for upgrading users, please see the notes at the bottom) Bazel brought a lot of nice things to the table, such as rebuilds based on content changes instead of modification times, caching of build products, detection of incorrect build rules via a sandbox, and so on. Rewriting the build in Bazel was also an opportunity to improve on the Makefile-based build we had prior, which was pretty poor: most dependencies were external or not pinned, and the build graph was poorly defined and mostly serialized. It was not uncommon for fresh checkouts to fail due to floating dependencies, or for things to break when trying to switch to an older commit. For day-to-day development, I think Bazel served us reasonably well - we could generally switch between branches while being confident that builds would be correct and reasonably fast, and not require full rebuilds (except on Windows, where the lack of a sandbox and the TS rules would cause build breakages when TS files were renamed/removed). Bazel achieves that reliability by defining rules for each programming language that define how source files should be turned into outputs. For the rules to work with Bazel's sandboxing approach, they often have to reimplement or partially bypass the standard tools that each programming language provides. The Rust rules call Rust's compiler directly for example, instead of using Cargo, and the Python rules extract each PyPi package into a separate folder that gets added to sys.path. These separate language rules allow proper declaration of inputs and outputs, and offer some advantages such as caching of build products and fine-grained dependency installation. But they also bring some downsides: - The rules don't always support use-cases/platforms that the standard language tools do, meaning they need to be patched to be used. I've had to contribute a number of patches to the Rust, Python and JS rules to unblock various issues. - The dependencies we use with each language sometimes make assumptions that do not hold in Bazel, meaning they either need to be pinned or patched, or the language rules need to be adjusted to accommodate them. I was hopeful that after the initial setup work, things would be relatively smooth-sailing. Unfortunately, that has not proved to be the case. Things frequently broke when dependencies or the language rules were updated, and I began to get frustrated at the amount of Anki development time I was instead spending on build system upkeep. It's now about 2 years since switching to Bazel, and I think it's time to cut losses, and switch to something else that's a better fit. The new build system is based on a small build tool called Ninja, and some custom Rust code in build/. This means that to build Anki, Bazel is no longer required, but Ninja and Rust need to be installed on your system. Python and Node toolchains are automatically downloaded like in Bazel. This new build system should result in faster builds in some cases: - Because we're using cargo to build now, Rust builds are able to take advantage of pipelining and incremental debug builds, which we didn't have with Bazel. It's also easier to override the default linker on Linux/macOS, which can further improve speeds. - External Rust crates are now built with opt=1, which improves performance of debug builds. - Esbuild is now used to transpile TypeScript, instead of invoking the TypeScript compiler. This results in faster builds, by deferring typechecking to test/check time, and by allowing more work to happen in parallel. As an example of the differences, when testing with the mold linker on Linux, adding a new message to tags.proto (which triggers a recompile of the bulk of the Rust and TypeScript code) results in a compile that goes from about 22s on Bazel to about 7s in the new system. With the standard linker, it's about 9s. Some other changes of note: - Our Rust workspace now uses cargo-hakari to ensure all packages agree on available features, preventing unnecessary rebuilds. - pylib/anki is now a PEP420 implicit namespace, avoiding the need to merge source files and generated files into a single folder for running. By telling VSCode about the extra search path, code completion now works with generated files without needing to symlink them into the source folder. - qt/aqt can't use PEP420 as it's difficult to get rid of aqt/__init__.py. Instead, the generated files are now placed in a separate _aqt package that's added to the path. - ts/lib is now exposed as @tslib, so the source code and generated code can be provided under the same namespace without a merging step. - MyPy and PyLint are now invoked once for the entire codebase. - dprint will be used to format TypeScript/json files in the future instead of the slower prettier (currently turned off to avoid causing conflicts). It can automatically defer to prettier when formatting Svelte files. - svelte-check is now used for typechecking our Svelte code, which revealed a few typing issues that went undetected with the old system. - The Jest unit tests now work on Windows as well. If you're upgrading from Bazel, updated usage instructions are in docs/development.md and docs/build.md. A summary of the changes: - please remove node_modules and .bazel - install rustup (https://rustup.rs/) - install rsync if not already installed (on windows, use pacman - see docs/windows.md) - install Ninja (unzip from https://github.com/ninja-build/ninja/releases/tag/v1.11.1 and place on your path, or from your distro/homebrew if it's 1.10+) - update .vscode/settings.json from .vscode.dist
2022-11-27 06:24:20 +01:00
const renderError = (type: string) => (error: unknown): string => {
const errorMessage = String(error).substring(0, 2000);
let errorStack: string;
if (error instanceof Error) {
errorStack = String(error.stack).substring(0, 2000);
} else {
errorStack = "";
}
return `<div>Invalid ${type} on card: ${errorMessage}\n${errorStack}</div>`.replace(
/\n/g,
"<br>",
);
};
2021-07-12 22:10:40 +02:00
export async function _updateQA(
2021-07-05 12:45:44 +02:00
html: string,
_unusused: unknown,
onupdate: Callback,
onshown: Callback,
2021-07-05 12:45:44 +02:00
): Promise<void> {
2021-07-12 15:00:36 +02:00
onUpdateHook.length = 0;
onUpdateHook.push(onupdate);
onShownHook.length = 0;
onShownHook.push(onshown);
2021-07-05 12:45:44 +02:00
const qa = document.getElementById("qa")!;
await preloadResources(html);
2022-11-04 01:07:51 +01:00
2021-07-16 17:26:04 +02:00
qa.style.opacity = "0";
2021-07-05 12:45:44 +02:00
try {
await setInnerHTML(qa, html);
2021-07-05 12:45:44 +02:00
} catch (error) {
await setInnerHTML(qa, renderError("html")(error));
2021-07-05 12:45:44 +02:00
}
await _runHook(onUpdateHook);
2021-07-16 16:33:12 +02:00
Auto-hide toolbar in Reviewer (#2262) * Give webviews a slide-in animation if reduced motion isn't set. * Auto-hide toolbar in review mode moving the mouse above the main webview expands the toolbar. When the mouse leaves the toolbar, it will collapse after a delay of 2s. * Save some space on bottom toolbars * Use props for all hard-coded transition durations and decrease most commonly used duration (200ms) to 150ms. * Move auto-hide logic into ToolbarWebView and handle auto-hide specific events in the respective webview subclasses. * Fix typing issues * Fix flickering issue * Add auto_hide_toolbar opt-in to preferences * Rename hide_toolbar to collapse_toolbar to better describe the dock-like behaviour. * Rename setting to minimize_distractions * Reduce calls to pm in eventFilter * Run formatter * Revert setting title to something more specific * Increase default animation time to 180ms * Inset toolbar in review mode when auto-hide is not enabled. * Use card background on toolbar and add glass effect * Use flatten/elevate over inset/outset * Use flatten/elevate over inset/outset * Update toolbar.py * Fix toolbar background delay * Tweak styles * Use "collapse" instead of "auto-hide" * Fix background misalignment in collapse mode * Do not collapse toolbar when pointer is outside MainWebView * Reduce hide_timer interval to 1000ms * Use CSS to hide toolbar instead of setting webview height * Add guard to prevent backdrop-filter: blur on Qt 5.14 * Apply transition to body instead of toolbar to not complicate things for #2301. * Fix Qt 5.14 and apply guard globally * Fix background image scaling difference * Tweak preference wording (dae)
2023-01-09 05:39:31 +01:00
// dynamic toolbar background
bridgeCommand("updateToolbar");
2021-07-16 16:33:12 +02:00
// wait for mathjax to ready
await MathJax.startup.promise
.then(() => {
// clear MathJax buffers from previous typesets
MathJax.typesetClear();
return MathJax.typesetPromise([qa]);
})
.catch(renderError("MathJax"));
2021-07-16 17:26:04 +02:00
qa.style.opacity = "1";
2021-07-05 12:45:44 +02:00
await _runHook(onShownHook);
}
export function _showQuestion(q: string, a: string, bodyclass: string): void {
_queueAction(() =>
_updateQA(
q,
null,
Move away from Bazel (#2202) (for upgrading users, please see the notes at the bottom) Bazel brought a lot of nice things to the table, such as rebuilds based on content changes instead of modification times, caching of build products, detection of incorrect build rules via a sandbox, and so on. Rewriting the build in Bazel was also an opportunity to improve on the Makefile-based build we had prior, which was pretty poor: most dependencies were external or not pinned, and the build graph was poorly defined and mostly serialized. It was not uncommon for fresh checkouts to fail due to floating dependencies, or for things to break when trying to switch to an older commit. For day-to-day development, I think Bazel served us reasonably well - we could generally switch between branches while being confident that builds would be correct and reasonably fast, and not require full rebuilds (except on Windows, where the lack of a sandbox and the TS rules would cause build breakages when TS files were renamed/removed). Bazel achieves that reliability by defining rules for each programming language that define how source files should be turned into outputs. For the rules to work with Bazel's sandboxing approach, they often have to reimplement or partially bypass the standard tools that each programming language provides. The Rust rules call Rust's compiler directly for example, instead of using Cargo, and the Python rules extract each PyPi package into a separate folder that gets added to sys.path. These separate language rules allow proper declaration of inputs and outputs, and offer some advantages such as caching of build products and fine-grained dependency installation. But they also bring some downsides: - The rules don't always support use-cases/platforms that the standard language tools do, meaning they need to be patched to be used. I've had to contribute a number of patches to the Rust, Python and JS rules to unblock various issues. - The dependencies we use with each language sometimes make assumptions that do not hold in Bazel, meaning they either need to be pinned or patched, or the language rules need to be adjusted to accommodate them. I was hopeful that after the initial setup work, things would be relatively smooth-sailing. Unfortunately, that has not proved to be the case. Things frequently broke when dependencies or the language rules were updated, and I began to get frustrated at the amount of Anki development time I was instead spending on build system upkeep. It's now about 2 years since switching to Bazel, and I think it's time to cut losses, and switch to something else that's a better fit. The new build system is based on a small build tool called Ninja, and some custom Rust code in build/. This means that to build Anki, Bazel is no longer required, but Ninja and Rust need to be installed on your system. Python and Node toolchains are automatically downloaded like in Bazel. This new build system should result in faster builds in some cases: - Because we're using cargo to build now, Rust builds are able to take advantage of pipelining and incremental debug builds, which we didn't have with Bazel. It's also easier to override the default linker on Linux/macOS, which can further improve speeds. - External Rust crates are now built with opt=1, which improves performance of debug builds. - Esbuild is now used to transpile TypeScript, instead of invoking the TypeScript compiler. This results in faster builds, by deferring typechecking to test/check time, and by allowing more work to happen in parallel. As an example of the differences, when testing with the mold linker on Linux, adding a new message to tags.proto (which triggers a recompile of the bulk of the Rust and TypeScript code) results in a compile that goes from about 22s on Bazel to about 7s in the new system. With the standard linker, it's about 9s. Some other changes of note: - Our Rust workspace now uses cargo-hakari to ensure all packages agree on available features, preventing unnecessary rebuilds. - pylib/anki is now a PEP420 implicit namespace, avoiding the need to merge source files and generated files into a single folder for running. By telling VSCode about the extra search path, code completion now works with generated files without needing to symlink them into the source folder. - qt/aqt can't use PEP420 as it's difficult to get rid of aqt/__init__.py. Instead, the generated files are now placed in a separate _aqt package that's added to the path. - ts/lib is now exposed as @tslib, so the source code and generated code can be provided under the same namespace without a merging step. - MyPy and PyLint are now invoked once for the entire codebase. - dprint will be used to format TypeScript/json files in the future instead of the slower prettier (currently turned off to avoid causing conflicts). It can automatically defer to prettier when formatting Svelte files. - svelte-check is now used for typechecking our Svelte code, which revealed a few typing issues that went undetected with the old system. - The Jest unit tests now work on Windows as well. If you're upgrading from Bazel, updated usage instructions are in docs/development.md and docs/build.md. A summary of the changes: - please remove node_modules and .bazel - install rustup (https://rustup.rs/) - install rsync if not already installed (on windows, use pacman - see docs/windows.md) - install Ninja (unzip from https://github.com/ninja-build/ninja/releases/tag/v1.11.1 and place on your path, or from your distro/homebrew if it's 1.10+) - update .vscode/settings.json from .vscode.dist
2022-11-27 06:24:20 +01:00
function() {
2021-07-05 12:45:44 +02:00
// return to top of window
window.scrollTo(0, 0);
document.body.className = bodyclass;
},
Move away from Bazel (#2202) (for upgrading users, please see the notes at the bottom) Bazel brought a lot of nice things to the table, such as rebuilds based on content changes instead of modification times, caching of build products, detection of incorrect build rules via a sandbox, and so on. Rewriting the build in Bazel was also an opportunity to improve on the Makefile-based build we had prior, which was pretty poor: most dependencies were external or not pinned, and the build graph was poorly defined and mostly serialized. It was not uncommon for fresh checkouts to fail due to floating dependencies, or for things to break when trying to switch to an older commit. For day-to-day development, I think Bazel served us reasonably well - we could generally switch between branches while being confident that builds would be correct and reasonably fast, and not require full rebuilds (except on Windows, where the lack of a sandbox and the TS rules would cause build breakages when TS files were renamed/removed). Bazel achieves that reliability by defining rules for each programming language that define how source files should be turned into outputs. For the rules to work with Bazel's sandboxing approach, they often have to reimplement or partially bypass the standard tools that each programming language provides. The Rust rules call Rust's compiler directly for example, instead of using Cargo, and the Python rules extract each PyPi package into a separate folder that gets added to sys.path. These separate language rules allow proper declaration of inputs and outputs, and offer some advantages such as caching of build products and fine-grained dependency installation. But they also bring some downsides: - The rules don't always support use-cases/platforms that the standard language tools do, meaning they need to be patched to be used. I've had to contribute a number of patches to the Rust, Python and JS rules to unblock various issues. - The dependencies we use with each language sometimes make assumptions that do not hold in Bazel, meaning they either need to be pinned or patched, or the language rules need to be adjusted to accommodate them. I was hopeful that after the initial setup work, things would be relatively smooth-sailing. Unfortunately, that has not proved to be the case. Things frequently broke when dependencies or the language rules were updated, and I began to get frustrated at the amount of Anki development time I was instead spending on build system upkeep. It's now about 2 years since switching to Bazel, and I think it's time to cut losses, and switch to something else that's a better fit. The new build system is based on a small build tool called Ninja, and some custom Rust code in build/. This means that to build Anki, Bazel is no longer required, but Ninja and Rust need to be installed on your system. Python and Node toolchains are automatically downloaded like in Bazel. This new build system should result in faster builds in some cases: - Because we're using cargo to build now, Rust builds are able to take advantage of pipelining and incremental debug builds, which we didn't have with Bazel. It's also easier to override the default linker on Linux/macOS, which can further improve speeds. - External Rust crates are now built with opt=1, which improves performance of debug builds. - Esbuild is now used to transpile TypeScript, instead of invoking the TypeScript compiler. This results in faster builds, by deferring typechecking to test/check time, and by allowing more work to happen in parallel. As an example of the differences, when testing with the mold linker on Linux, adding a new message to tags.proto (which triggers a recompile of the bulk of the Rust and TypeScript code) results in a compile that goes from about 22s on Bazel to about 7s in the new system. With the standard linker, it's about 9s. Some other changes of note: - Our Rust workspace now uses cargo-hakari to ensure all packages agree on available features, preventing unnecessary rebuilds. - pylib/anki is now a PEP420 implicit namespace, avoiding the need to merge source files and generated files into a single folder for running. By telling VSCode about the extra search path, code completion now works with generated files without needing to symlink them into the source folder. - qt/aqt can't use PEP420 as it's difficult to get rid of aqt/__init__.py. Instead, the generated files are now placed in a separate _aqt package that's added to the path. - ts/lib is now exposed as @tslib, so the source code and generated code can be provided under the same namespace without a merging step. - MyPy and PyLint are now invoked once for the entire codebase. - dprint will be used to format TypeScript/json files in the future instead of the slower prettier (currently turned off to avoid causing conflicts). It can automatically defer to prettier when formatting Svelte files. - svelte-check is now used for typechecking our Svelte code, which revealed a few typing issues that went undetected with the old system. - The Jest unit tests now work on Windows as well. If you're upgrading from Bazel, updated usage instructions are in docs/development.md and docs/build.md. A summary of the changes: - please remove node_modules and .bazel - install rustup (https://rustup.rs/) - install rsync if not already installed (on windows, use pacman - see docs/windows.md) - install Ninja (unzip from https://github.com/ninja-build/ninja/releases/tag/v1.11.1 and place on your path, or from your distro/homebrew if it's 1.10+) - update .vscode/settings.json from .vscode.dist
2022-11-27 06:24:20 +01:00
function() {
2021-07-05 12:45:44 +02:00
// focus typing area if visible
2021-07-12 15:00:36 +02:00
typeans = document.getElementById("typeans") as HTMLInputElement;
2021-07-05 12:45:44 +02:00
if (typeans) {
typeans.focus();
}
// preload images
allImagesLoaded().then(() => preloadAnswerImages(a));
},
Move away from Bazel (#2202) (for upgrading users, please see the notes at the bottom) Bazel brought a lot of nice things to the table, such as rebuilds based on content changes instead of modification times, caching of build products, detection of incorrect build rules via a sandbox, and so on. Rewriting the build in Bazel was also an opportunity to improve on the Makefile-based build we had prior, which was pretty poor: most dependencies were external or not pinned, and the build graph was poorly defined and mostly serialized. It was not uncommon for fresh checkouts to fail due to floating dependencies, or for things to break when trying to switch to an older commit. For day-to-day development, I think Bazel served us reasonably well - we could generally switch between branches while being confident that builds would be correct and reasonably fast, and not require full rebuilds (except on Windows, where the lack of a sandbox and the TS rules would cause build breakages when TS files were renamed/removed). Bazel achieves that reliability by defining rules for each programming language that define how source files should be turned into outputs. For the rules to work with Bazel's sandboxing approach, they often have to reimplement or partially bypass the standard tools that each programming language provides. The Rust rules call Rust's compiler directly for example, instead of using Cargo, and the Python rules extract each PyPi package into a separate folder that gets added to sys.path. These separate language rules allow proper declaration of inputs and outputs, and offer some advantages such as caching of build products and fine-grained dependency installation. But they also bring some downsides: - The rules don't always support use-cases/platforms that the standard language tools do, meaning they need to be patched to be used. I've had to contribute a number of patches to the Rust, Python and JS rules to unblock various issues. - The dependencies we use with each language sometimes make assumptions that do not hold in Bazel, meaning they either need to be pinned or patched, or the language rules need to be adjusted to accommodate them. I was hopeful that after the initial setup work, things would be relatively smooth-sailing. Unfortunately, that has not proved to be the case. Things frequently broke when dependencies or the language rules were updated, and I began to get frustrated at the amount of Anki development time I was instead spending on build system upkeep. It's now about 2 years since switching to Bazel, and I think it's time to cut losses, and switch to something else that's a better fit. The new build system is based on a small build tool called Ninja, and some custom Rust code in build/. This means that to build Anki, Bazel is no longer required, but Ninja and Rust need to be installed on your system. Python and Node toolchains are automatically downloaded like in Bazel. This new build system should result in faster builds in some cases: - Because we're using cargo to build now, Rust builds are able to take advantage of pipelining and incremental debug builds, which we didn't have with Bazel. It's also easier to override the default linker on Linux/macOS, which can further improve speeds. - External Rust crates are now built with opt=1, which improves performance of debug builds. - Esbuild is now used to transpile TypeScript, instead of invoking the TypeScript compiler. This results in faster builds, by deferring typechecking to test/check time, and by allowing more work to happen in parallel. As an example of the differences, when testing with the mold linker on Linux, adding a new message to tags.proto (which triggers a recompile of the bulk of the Rust and TypeScript code) results in a compile that goes from about 22s on Bazel to about 7s in the new system. With the standard linker, it's about 9s. Some other changes of note: - Our Rust workspace now uses cargo-hakari to ensure all packages agree on available features, preventing unnecessary rebuilds. - pylib/anki is now a PEP420 implicit namespace, avoiding the need to merge source files and generated files into a single folder for running. By telling VSCode about the extra search path, code completion now works with generated files without needing to symlink them into the source folder. - qt/aqt can't use PEP420 as it's difficult to get rid of aqt/__init__.py. Instead, the generated files are now placed in a separate _aqt package that's added to the path. - ts/lib is now exposed as @tslib, so the source code and generated code can be provided under the same namespace without a merging step. - MyPy and PyLint are now invoked once for the entire codebase. - dprint will be used to format TypeScript/json files in the future instead of the slower prettier (currently turned off to avoid causing conflicts). It can automatically defer to prettier when formatting Svelte files. - svelte-check is now used for typechecking our Svelte code, which revealed a few typing issues that went undetected with the old system. - The Jest unit tests now work on Windows as well. If you're upgrading from Bazel, updated usage instructions are in docs/development.md and docs/build.md. A summary of the changes: - please remove node_modules and .bazel - install rustup (https://rustup.rs/) - install rsync if not already installed (on windows, use pacman - see docs/windows.md) - install Ninja (unzip from https://github.com/ninja-build/ninja/releases/tag/v1.11.1 and place on your path, or from your distro/homebrew if it's 1.10+) - update .vscode/settings.json from .vscode.dist
2022-11-27 06:24:20 +01:00
)
2021-07-05 12:45:44 +02:00
);
}
2021-07-12 17:11:14 +02:00
function scrollToAnswer(): void {
document.getElementById("answer")?.scrollIntoView();
}
2021-07-05 12:45:44 +02:00
export function _showAnswer(a: string, bodyclass: string): void {
_queueAction(() =>
_updateQA(
a,
null,
Move away from Bazel (#2202) (for upgrading users, please see the notes at the bottom) Bazel brought a lot of nice things to the table, such as rebuilds based on content changes instead of modification times, caching of build products, detection of incorrect build rules via a sandbox, and so on. Rewriting the build in Bazel was also an opportunity to improve on the Makefile-based build we had prior, which was pretty poor: most dependencies were external or not pinned, and the build graph was poorly defined and mostly serialized. It was not uncommon for fresh checkouts to fail due to floating dependencies, or for things to break when trying to switch to an older commit. For day-to-day development, I think Bazel served us reasonably well - we could generally switch between branches while being confident that builds would be correct and reasonably fast, and not require full rebuilds (except on Windows, where the lack of a sandbox and the TS rules would cause build breakages when TS files were renamed/removed). Bazel achieves that reliability by defining rules for each programming language that define how source files should be turned into outputs. For the rules to work with Bazel's sandboxing approach, they often have to reimplement or partially bypass the standard tools that each programming language provides. The Rust rules call Rust's compiler directly for example, instead of using Cargo, and the Python rules extract each PyPi package into a separate folder that gets added to sys.path. These separate language rules allow proper declaration of inputs and outputs, and offer some advantages such as caching of build products and fine-grained dependency installation. But they also bring some downsides: - The rules don't always support use-cases/platforms that the standard language tools do, meaning they need to be patched to be used. I've had to contribute a number of patches to the Rust, Python and JS rules to unblock various issues. - The dependencies we use with each language sometimes make assumptions that do not hold in Bazel, meaning they either need to be pinned or patched, or the language rules need to be adjusted to accommodate them. I was hopeful that after the initial setup work, things would be relatively smooth-sailing. Unfortunately, that has not proved to be the case. Things frequently broke when dependencies or the language rules were updated, and I began to get frustrated at the amount of Anki development time I was instead spending on build system upkeep. It's now about 2 years since switching to Bazel, and I think it's time to cut losses, and switch to something else that's a better fit. The new build system is based on a small build tool called Ninja, and some custom Rust code in build/. This means that to build Anki, Bazel is no longer required, but Ninja and Rust need to be installed on your system. Python and Node toolchains are automatically downloaded like in Bazel. This new build system should result in faster builds in some cases: - Because we're using cargo to build now, Rust builds are able to take advantage of pipelining and incremental debug builds, which we didn't have with Bazel. It's also easier to override the default linker on Linux/macOS, which can further improve speeds. - External Rust crates are now built with opt=1, which improves performance of debug builds. - Esbuild is now used to transpile TypeScript, instead of invoking the TypeScript compiler. This results in faster builds, by deferring typechecking to test/check time, and by allowing more work to happen in parallel. As an example of the differences, when testing with the mold linker on Linux, adding a new message to tags.proto (which triggers a recompile of the bulk of the Rust and TypeScript code) results in a compile that goes from about 22s on Bazel to about 7s in the new system. With the standard linker, it's about 9s. Some other changes of note: - Our Rust workspace now uses cargo-hakari to ensure all packages agree on available features, preventing unnecessary rebuilds. - pylib/anki is now a PEP420 implicit namespace, avoiding the need to merge source files and generated files into a single folder for running. By telling VSCode about the extra search path, code completion now works with generated files without needing to symlink them into the source folder. - qt/aqt can't use PEP420 as it's difficult to get rid of aqt/__init__.py. Instead, the generated files are now placed in a separate _aqt package that's added to the path. - ts/lib is now exposed as @tslib, so the source code and generated code can be provided under the same namespace without a merging step. - MyPy and PyLint are now invoked once for the entire codebase. - dprint will be used to format TypeScript/json files in the future instead of the slower prettier (currently turned off to avoid causing conflicts). It can automatically defer to prettier when formatting Svelte files. - svelte-check is now used for typechecking our Svelte code, which revealed a few typing issues that went undetected with the old system. - The Jest unit tests now work on Windows as well. If you're upgrading from Bazel, updated usage instructions are in docs/development.md and docs/build.md. A summary of the changes: - please remove node_modules and .bazel - install rustup (https://rustup.rs/) - install rsync if not already installed (on windows, use pacman - see docs/windows.md) - install Ninja (unzip from https://github.com/ninja-build/ninja/releases/tag/v1.11.1 and place on your path, or from your distro/homebrew if it's 1.10+) - update .vscode/settings.json from .vscode.dist
2022-11-27 06:24:20 +01:00
function() {
2021-07-05 12:45:44 +02:00
if (bodyclass) {
// when previewing
document.body.className = bodyclass;
}
// avoid scrolling to the answer until images load
allImagesLoaded().then(scrollToAnswer);
},
Move away from Bazel (#2202) (for upgrading users, please see the notes at the bottom) Bazel brought a lot of nice things to the table, such as rebuilds based on content changes instead of modification times, caching of build products, detection of incorrect build rules via a sandbox, and so on. Rewriting the build in Bazel was also an opportunity to improve on the Makefile-based build we had prior, which was pretty poor: most dependencies were external or not pinned, and the build graph was poorly defined and mostly serialized. It was not uncommon for fresh checkouts to fail due to floating dependencies, or for things to break when trying to switch to an older commit. For day-to-day development, I think Bazel served us reasonably well - we could generally switch between branches while being confident that builds would be correct and reasonably fast, and not require full rebuilds (except on Windows, where the lack of a sandbox and the TS rules would cause build breakages when TS files were renamed/removed). Bazel achieves that reliability by defining rules for each programming language that define how source files should be turned into outputs. For the rules to work with Bazel's sandboxing approach, they often have to reimplement or partially bypass the standard tools that each programming language provides. The Rust rules call Rust's compiler directly for example, instead of using Cargo, and the Python rules extract each PyPi package into a separate folder that gets added to sys.path. These separate language rules allow proper declaration of inputs and outputs, and offer some advantages such as caching of build products and fine-grained dependency installation. But they also bring some downsides: - The rules don't always support use-cases/platforms that the standard language tools do, meaning they need to be patched to be used. I've had to contribute a number of patches to the Rust, Python and JS rules to unblock various issues. - The dependencies we use with each language sometimes make assumptions that do not hold in Bazel, meaning they either need to be pinned or patched, or the language rules need to be adjusted to accommodate them. I was hopeful that after the initial setup work, things would be relatively smooth-sailing. Unfortunately, that has not proved to be the case. Things frequently broke when dependencies or the language rules were updated, and I began to get frustrated at the amount of Anki development time I was instead spending on build system upkeep. It's now about 2 years since switching to Bazel, and I think it's time to cut losses, and switch to something else that's a better fit. The new build system is based on a small build tool called Ninja, and some custom Rust code in build/. This means that to build Anki, Bazel is no longer required, but Ninja and Rust need to be installed on your system. Python and Node toolchains are automatically downloaded like in Bazel. This new build system should result in faster builds in some cases: - Because we're using cargo to build now, Rust builds are able to take advantage of pipelining and incremental debug builds, which we didn't have with Bazel. It's also easier to override the default linker on Linux/macOS, which can further improve speeds. - External Rust crates are now built with opt=1, which improves performance of debug builds. - Esbuild is now used to transpile TypeScript, instead of invoking the TypeScript compiler. This results in faster builds, by deferring typechecking to test/check time, and by allowing more work to happen in parallel. As an example of the differences, when testing with the mold linker on Linux, adding a new message to tags.proto (which triggers a recompile of the bulk of the Rust and TypeScript code) results in a compile that goes from about 22s on Bazel to about 7s in the new system. With the standard linker, it's about 9s. Some other changes of note: - Our Rust workspace now uses cargo-hakari to ensure all packages agree on available features, preventing unnecessary rebuilds. - pylib/anki is now a PEP420 implicit namespace, avoiding the need to merge source files and generated files into a single folder for running. By telling VSCode about the extra search path, code completion now works with generated files without needing to symlink them into the source folder. - qt/aqt can't use PEP420 as it's difficult to get rid of aqt/__init__.py. Instead, the generated files are now placed in a separate _aqt package that's added to the path. - ts/lib is now exposed as @tslib, so the source code and generated code can be provided under the same namespace without a merging step. - MyPy and PyLint are now invoked once for the entire codebase. - dprint will be used to format TypeScript/json files in the future instead of the slower prettier (currently turned off to avoid causing conflicts). It can automatically defer to prettier when formatting Svelte files. - svelte-check is now used for typechecking our Svelte code, which revealed a few typing issues that went undetected with the old system. - The Jest unit tests now work on Windows as well. If you're upgrading from Bazel, updated usage instructions are in docs/development.md and docs/build.md. A summary of the changes: - please remove node_modules and .bazel - install rustup (https://rustup.rs/) - install rsync if not already installed (on windows, use pacman - see docs/windows.md) - install Ninja (unzip from https://github.com/ninja-build/ninja/releases/tag/v1.11.1 and place on your path, or from your distro/homebrew if it's 1.10+) - update .vscode/settings.json from .vscode.dist
2022-11-27 06:24:20 +01:00
function() {
2021-07-13 00:30:20 +02:00
/* noop */
},
Move away from Bazel (#2202) (for upgrading users, please see the notes at the bottom) Bazel brought a lot of nice things to the table, such as rebuilds based on content changes instead of modification times, caching of build products, detection of incorrect build rules via a sandbox, and so on. Rewriting the build in Bazel was also an opportunity to improve on the Makefile-based build we had prior, which was pretty poor: most dependencies were external or not pinned, and the build graph was poorly defined and mostly serialized. It was not uncommon for fresh checkouts to fail due to floating dependencies, or for things to break when trying to switch to an older commit. For day-to-day development, I think Bazel served us reasonably well - we could generally switch between branches while being confident that builds would be correct and reasonably fast, and not require full rebuilds (except on Windows, where the lack of a sandbox and the TS rules would cause build breakages when TS files were renamed/removed). Bazel achieves that reliability by defining rules for each programming language that define how source files should be turned into outputs. For the rules to work with Bazel's sandboxing approach, they often have to reimplement or partially bypass the standard tools that each programming language provides. The Rust rules call Rust's compiler directly for example, instead of using Cargo, and the Python rules extract each PyPi package into a separate folder that gets added to sys.path. These separate language rules allow proper declaration of inputs and outputs, and offer some advantages such as caching of build products and fine-grained dependency installation. But they also bring some downsides: - The rules don't always support use-cases/platforms that the standard language tools do, meaning they need to be patched to be used. I've had to contribute a number of patches to the Rust, Python and JS rules to unblock various issues. - The dependencies we use with each language sometimes make assumptions that do not hold in Bazel, meaning they either need to be pinned or patched, or the language rules need to be adjusted to accommodate them. I was hopeful that after the initial setup work, things would be relatively smooth-sailing. Unfortunately, that has not proved to be the case. Things frequently broke when dependencies or the language rules were updated, and I began to get frustrated at the amount of Anki development time I was instead spending on build system upkeep. It's now about 2 years since switching to Bazel, and I think it's time to cut losses, and switch to something else that's a better fit. The new build system is based on a small build tool called Ninja, and some custom Rust code in build/. This means that to build Anki, Bazel is no longer required, but Ninja and Rust need to be installed on your system. Python and Node toolchains are automatically downloaded like in Bazel. This new build system should result in faster builds in some cases: - Because we're using cargo to build now, Rust builds are able to take advantage of pipelining and incremental debug builds, which we didn't have with Bazel. It's also easier to override the default linker on Linux/macOS, which can further improve speeds. - External Rust crates are now built with opt=1, which improves performance of debug builds. - Esbuild is now used to transpile TypeScript, instead of invoking the TypeScript compiler. This results in faster builds, by deferring typechecking to test/check time, and by allowing more work to happen in parallel. As an example of the differences, when testing with the mold linker on Linux, adding a new message to tags.proto (which triggers a recompile of the bulk of the Rust and TypeScript code) results in a compile that goes from about 22s on Bazel to about 7s in the new system. With the standard linker, it's about 9s. Some other changes of note: - Our Rust workspace now uses cargo-hakari to ensure all packages agree on available features, preventing unnecessary rebuilds. - pylib/anki is now a PEP420 implicit namespace, avoiding the need to merge source files and generated files into a single folder for running. By telling VSCode about the extra search path, code completion now works with generated files without needing to symlink them into the source folder. - qt/aqt can't use PEP420 as it's difficult to get rid of aqt/__init__.py. Instead, the generated files are now placed in a separate _aqt package that's added to the path. - ts/lib is now exposed as @tslib, so the source code and generated code can be provided under the same namespace without a merging step. - MyPy and PyLint are now invoked once for the entire codebase. - dprint will be used to format TypeScript/json files in the future instead of the slower prettier (currently turned off to avoid causing conflicts). It can automatically defer to prettier when formatting Svelte files. - svelte-check is now used for typechecking our Svelte code, which revealed a few typing issues that went undetected with the old system. - The Jest unit tests now work on Windows as well. If you're upgrading from Bazel, updated usage instructions are in docs/development.md and docs/build.md. A summary of the changes: - please remove node_modules and .bazel - install rustup (https://rustup.rs/) - install rsync if not already installed (on windows, use pacman - see docs/windows.md) - install Ninja (unzip from https://github.com/ninja-build/ninja/releases/tag/v1.11.1 and place on your path, or from your distro/homebrew if it's 1.10+) - update .vscode/settings.json from .vscode.dist
2022-11-27 06:24:20 +01:00
)
2021-07-05 12:45:44 +02:00
);
}
export function _drawFlag(flag: 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7): void {
const elem = document.getElementById("_flag")!;
2021-07-12 17:11:14 +02:00
elem.toggleAttribute("hidden", flag === 0);
Introduce new color palette using Sass maps (#2016) * Remove --medium-border variable * Implement color palette using Sass maps I hand-picked the gray tones, the other colors are from the Tailwind CSS v3 palette. Significant changes: - light theme is brighter - dark theme is darker - borders are softer I also deleted some platform- and night-mode-specific code. * Use custom colors for note view switch * Use same placeholder color for all inputs * Skew color palette for more dark values by removing gray[3], which wasn't used anywhere. Slight adjustments were made to the darker tones. * Adjust frame- window- and border colors * Give deck browser entries --frame-bg as background color * Define styling for QComboBox and QLineEdit globally * Experiment with CSS filter for inline-colors Inside darker inputs, some colors like dark blue will be hard to read, so we could try to improve text-color contrast with global adjustments depending on the theme. * Use different map structure for _vars.scss after @hgiesel's idea: https://github.com/ankitects/anki/pull/2016#discussion_r947087871 * Move custom QLineEdit styles out of searchbar.py * Merge branch 'main' into color-palette * Revert QComboBox stylesheet override * Align gray color palette more with macOS * Adjust light theme * Use --slightly-grey-text for options tab color * Replace gray tones with more neutral values * Improve categorization of global colors by renaming almost all of them and sorting them into separate maps. * Saturate highlight-bg in light theme * Tweak gray tones * Adjust box-shadow of EditingArea to make fields look inset * Add Sass functions to access color palette and semantic variables in response to https://github.com/ankitects/anki/pull/2016#issuecomment-1220571076 * Showcase use of access functions in several locations @hgiesel in buttons.scss I access the color palette directly. Is this what you meant by "... keep it local to the component, and possibly make it global at a later time ..."? * Fix focus box shadow transition and remove default shadow for a cleaner look I couldn't quite get the inset look the way I wanted, because inset box-shadows do not respect the border radius, therefore causing aliasing. * Tweak light theme border and shadow colors * Add functions and colors to base_lib * Add vars_lib as dependency to base_lib and button_mixins_lib * Improve uses of default-themed variables * Use old --frame-bg color and use darker tone for canvas-default * Return CSS var by default and add palette-of function for raw value * Showcase use of palette-of function The #{...} syntax is required only because the use cases are CSS var definitions. In other cases a simple palette-of(keyword, theme) would suffice. * Light theme: decrease brightness of canvas-default and adjust fg-default * Use canvas-inset variable for switch knob * Adjust light theme * Add back box-shadow to EditingArea * Light theme: darken background and flatten transition also set hue and saturation of gray-8 to 0 (like all the other grays). * Reduce flag colors to single default value * Tweak card/note accent colors * Experiment with inset look for fields again Is this too dark in night mode? It's the same color used for all other text inputs. * Dark theme: make border-default one shade darker * Tweak inset shadow color * Dark theme: make border-faint darker than canvas-default meaning two shades darker than it currently was. * Fix PlainTextInput not expanding * Dark theme: use less saturated flag colors * Adjust gray tones * Fix nested variables not getting extracted correctly * Rename canvas-outset to canvas-elevated * Light theme: darken canvas-default * Make canvas-elevated a bit darker * Rename variables and use them in various components * Refactor button mixins * Remove fusion vars from Anki * Adjust button gradients * Refactor button mixins * Fix deck browser table td background color * Use color function in buttons.scss * Rework QTabWidget stylesheet * Fix crash on browser open * Perfect QTableView header * Fix bottom toolbar button gradient * Fix focus outline of bottom toolbar buttons * Fix custom webview scrollbar * Fix uses of vars in various webviews The command @use vars as * lead to repeated inclusion of the CSS vars. * Enable primary button color with mixin * Run prettier * Fix Python code style issues * Tweak colors * Lighten scrollbar shades in light theme * Fix code style issues caused by merge * Fix harsh border color in editor caused by leftover --medium-border variables, probably introduced with a merge commit. * Compile Sass before extracting Python colors/props This means the Python side doesn't need to worry about the map structure and Sass functions, just copy the output CSS values. * Desaturate primary button colors by 10% * Convert accidentally capitalized variable names to lowercase * Simplify color definitions with qcolor function * Remove default border-focus variable * Remove redundant colon * Apply custom scrollbar CSS only on Windows and Linux * Make border-subtle color brighter than background in dark theme * Make border-subtle color a shade brighter in light theme * Use border-subtle for NoteEditor and EditorToolbar border * Small patches
2022-09-16 06:11:18 +02:00
elem.style.color = `var(--flag-${flag})`;
2021-07-05 12:45:44 +02:00
}
export function _drawMark(mark: boolean): void {
2021-07-12 17:11:14 +02:00
document.getElementById("_mark")!.toggleAttribute("hidden", !mark);
2021-07-05 12:45:44 +02:00
}
export function _typeAnsPress(): void {
const code = (window.event as KeyboardEvent).code;
if (["Enter", "NumpadEnter"].includes(code)) {
bridgeCommand("ans");
}
}
export function _emulateMobile(enabled: boolean): void {
2021-07-12 17:11:14 +02:00
document.documentElement.classList.toggle("mobile", enabled);
2021-07-05 12:45:44 +02:00
}
// Block Qt's default drag & drop behavior by default
export function _blockDefaultDragDropBehavior(): void {
function handler(evt: DragEvent) {
evt.preventDefault();
}
document.ondragenter = handler;
document.ondragover = handler;
document.ondrop = handler;
}
// work around WebEngine/IME bug in Qt6
// https://github.com/ankitects/anki/issues/1952
const dummyButton = document.createElement("button");
dummyButton.style.position = "absolute";
dummyButton.style.opacity = "0";
document.addEventListener("focusout", (event) => {
// Prevent type box from losing focus when switching IMEs
if (!document.hasFocus()) {
return;
}
const target = event.target;
if (target instanceof HTMLInputElement || target instanceof HTMLTextAreaElement) {
dummyButton.style.left = `${window.scrollX}px`;
dummyButton.style.top = `${window.scrollY}px`;
document.body.appendChild(dummyButton);
dummyButton.focus();
document.body.removeChild(dummyButton);
}
});