2021-04-13 11:02:41 +02:00
|
|
|
<!--
|
|
|
|
Copyright: Ankitects Pty Ltd and contributors
|
|
|
|
License: GNU AGPL, version 3 or later; http://www.gnu.org/licenses/agpl.html
|
|
|
|
-->
|
2020-06-26 11:25:02 +02:00
|
|
|
<script lang="typescript">
|
2021-03-21 13:47:52 +01:00
|
|
|
import { createEventDispatcher } from "svelte";
|
2021-03-26 11:23:43 +01:00
|
|
|
|
refactor protobuf handling for split/import
In order to split backend.proto into a more manageable size, the protobuf
handling needed to be updated. This took more time than I would have
liked, as each language handles protobuf differently:
- The Python Protobuf code ignores "package" directives, and relies
solely on how the files are laid out on disk. While it would have been
nice to keep the generated files in a private subpackage, Protobuf gets
confused if the files are located in a location that does not match
their original .proto layout, so the old approach of storing them in
_backend/ will not work. They now clutter up pylib/anki instead. I'm
rather annoyed by that, but alternatives seem to be having to add an extra
level to the Protobuf path, making the other languages suffer, or trying
to hack around the issue by munging sys.modules.
- Protobufjs fails to expose packages if they don't start with a capital
letter, despite the fact that lowercase packages are the norm in most
languages :-( This required a patch to fix.
- Rust was the easiest, as Prost is relatively straightforward compared
to Google's tools.
The Protobuf files are now stored in /proto/anki, with a separate package
for each file. I've split backend.proto into a few files as a test, but
the majority of that work is still to come.
The Python Protobuf building is a bit of a hack at the moment, hard-coding
"proto" as the top level folder, but it seems to get the job done for now.
Also changed the workspace name, as there seems to be a number of Bazel
repos moving away from the more awkward reverse DNS naming style.
2021-07-10 09:50:18 +02:00
|
|
|
import type { Backend } from "lib/proto";
|
2021-03-21 13:47:52 +01:00
|
|
|
|
|
|
|
import Graph from "./Graph.svelte";
|
|
|
|
import InputBox from "./InputBox.svelte";
|
|
|
|
import HistogramGraph from "./HistogramGraph.svelte";
|
|
|
|
import GraphRangeRadios from "./GraphRangeRadios.svelte";
|
|
|
|
import TableData from "./TableData.svelte";
|
2021-04-14 23:46:13 +02:00
|
|
|
import type { PreferenceStore } from "sveltelib/preferences";
|
2021-03-21 13:47:52 +01:00
|
|
|
|
2020-11-01 05:26:58 +01:00
|
|
|
import type { HistogramData } from "./histogram-graph";
|
|
|
|
import { GraphRange, RevlogRange } from "./graph-helpers";
|
2021-01-26 12:41:22 +01:00
|
|
|
import type { TableDatum, SearchEventMap } from "./graph-helpers";
|
2020-11-01 05:26:58 +01:00
|
|
|
import { gatherData, buildHistogram } from "./future-due";
|
|
|
|
import type { GraphData } from "./future-due";
|
2020-06-26 11:25:02 +02:00
|
|
|
|
refactor protobuf handling for split/import
In order to split backend.proto into a more manageable size, the protobuf
handling needed to be updated. This took more time than I would have
liked, as each language handles protobuf differently:
- The Python Protobuf code ignores "package" directives, and relies
solely on how the files are laid out on disk. While it would have been
nice to keep the generated files in a private subpackage, Protobuf gets
confused if the files are located in a location that does not match
their original .proto layout, so the old approach of storing them in
_backend/ will not work. They now clutter up pylib/anki instead. I'm
rather annoyed by that, but alternatives seem to be having to add an extra
level to the Protobuf path, making the other languages suffer, or trying
to hack around the issue by munging sys.modules.
- Protobufjs fails to expose packages if they don't start with a capital
letter, despite the fact that lowercase packages are the norm in most
languages :-( This required a patch to fix.
- Rust was the easiest, as Prost is relatively straightforward compared
to Google's tools.
The Protobuf files are now stored in /proto/anki, with a separate package
for each file. I've split backend.proto into a few files as a test, but
the majority of that work is still to come.
The Python Protobuf building is a bit of a hack at the moment, hard-coding
"proto" as the top level folder, but it seems to get the job done for now.
Also changed the workspace name, as there seems to be a number of Bazel
repos moving away from the more awkward reverse DNS naming style.
2021-07-10 09:50:18 +02:00
|
|
|
export let sourceData: Backend.GraphsResponse | null = null;
|
2021-04-22 19:55:26 +02:00
|
|
|
import * as tr from "lib/i18n";
|
refactor protobuf handling for split/import
In order to split backend.proto into a more manageable size, the protobuf
handling needed to be updated. This took more time than I would have
liked, as each language handles protobuf differently:
- The Python Protobuf code ignores "package" directives, and relies
solely on how the files are laid out on disk. While it would have been
nice to keep the generated files in a private subpackage, Protobuf gets
confused if the files are located in a location that does not match
their original .proto layout, so the old approach of storing them in
_backend/ will not work. They now clutter up pylib/anki instead. I'm
rather annoyed by that, but alternatives seem to be having to add an extra
level to the Protobuf path, making the other languages suffer, or trying
to hack around the issue by munging sys.modules.
- Protobufjs fails to expose packages if they don't start with a capital
letter, despite the fact that lowercase packages are the norm in most
languages :-( This required a patch to fix.
- Rust was the easiest, as Prost is relatively straightforward compared
to Google's tools.
The Protobuf files are now stored in /proto/anki, with a separate package
for each file. I've split backend.proto into a few files as a test, but
the majority of that work is still to come.
The Python Protobuf building is a bit of a hack at the moment, hard-coding
"proto" as the top level folder, but it seems to get the job done for now.
Also changed the workspace name, as there seems to be a number of Bazel
repos moving away from the more awkward reverse DNS naming style.
2021-07-10 09:50:18 +02:00
|
|
|
export let preferences: PreferenceStore<Backend.GraphPreferences>;
|
2020-06-27 14:10:56 +02:00
|
|
|
|
2021-01-26 12:41:22 +01:00
|
|
|
const dispatch = createEventDispatcher<SearchEventMap>();
|
2021-01-25 16:33:18 +01:00
|
|
|
|
2020-06-26 11:25:02 +02:00
|
|
|
let graphData = null as GraphData | null;
|
|
|
|
let histogramData = null as HistogramData | null;
|
2020-08-04 07:15:57 +02:00
|
|
|
let tableData: TableDatum[] = [] as any;
|
2020-07-17 05:46:06 +02:00
|
|
|
let graphRange: GraphRange = GraphRange.Month;
|
2021-01-27 01:15:19 +01:00
|
|
|
let { browserLinksSupported, futureDueShowBacklog } = preferences;
|
2020-06-26 11:25:02 +02:00
|
|
|
|
|
|
|
$: if (sourceData) {
|
|
|
|
graphData = gatherData(sourceData);
|
|
|
|
}
|
|
|
|
|
|
|
|
$: if (graphData) {
|
2020-08-10 06:37:23 +02:00
|
|
|
({ histogramData, tableData } = buildHistogram(
|
2020-08-04 07:15:57 +02:00
|
|
|
graphData,
|
|
|
|
graphRange,
|
2021-01-27 01:15:19 +01:00
|
|
|
$futureDueShowBacklog,
|
2021-01-25 16:33:18 +01:00
|
|
|
dispatch,
|
2021-01-25 17:36:04 +01:00
|
|
|
$browserLinksSupported
|
2020-08-10 06:37:23 +02:00
|
|
|
));
|
2020-06-26 11:25:02 +02:00
|
|
|
}
|
2020-06-27 14:10:56 +02:00
|
|
|
|
2021-03-26 11:23:43 +01:00
|
|
|
const title = tr.statisticsFutureDueTitle();
|
|
|
|
const subtitle = tr.statisticsFutureDueSubtitle();
|
|
|
|
const backlogLabel = tr.statisticsBacklogCheckbox();
|
2020-06-26 11:25:02 +02:00
|
|
|
</script>
|
|
|
|
|
2021-03-21 13:47:52 +01:00
|
|
|
<Graph {title} {subtitle}>
|
|
|
|
<InputBox>
|
2020-08-10 06:37:23 +02:00
|
|
|
{#if graphData && graphData.haveBacklog}
|
|
|
|
<label>
|
2021-01-27 01:15:19 +01:00
|
|
|
<input type="checkbox" bind:checked={$futureDueShowBacklog} />
|
2020-08-10 06:37:23 +02:00
|
|
|
{backlogLabel}
|
|
|
|
</label>
|
|
|
|
{/if}
|
2020-06-26 11:25:02 +02:00
|
|
|
|
2021-03-26 11:23:43 +01:00
|
|
|
<GraphRangeRadios bind:graphRange revlogRange={RevlogRange.All} />
|
2021-03-21 13:47:52 +01:00
|
|
|
</InputBox>
|
2020-06-26 11:25:02 +02:00
|
|
|
|
2021-03-26 11:23:43 +01:00
|
|
|
<HistogramGraph data={histogramData} />
|
2020-06-26 11:25:02 +02:00
|
|
|
|
2021-03-26 11:23:43 +01:00
|
|
|
<TableData {tableData} />
|
2021-03-21 13:47:52 +01:00
|
|
|
</Graph>
|