astro
This commit is contained in:
parent
4acaafe8b9
commit
710b783ca7
22 changed files with 7873 additions and 192 deletions
23
docs/.gitignore
vendored
23
docs/.gitignore
vendored
|
@ -1,2 +1,21 @@
|
|||
book
|
||||
src/generated
|
||||
# build output
|
||||
dist/
|
||||
# generated types
|
||||
.astro/
|
||||
|
||||
# dependencies
|
||||
node_modules/
|
||||
|
||||
# logs
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
pnpm-debug.log*
|
||||
|
||||
|
||||
# environment variables
|
||||
.env
|
||||
.env.production
|
||||
|
||||
# macOS-specific files
|
||||
.DS_Store
|
||||
|
|
4
docs/.vscode/extensions.json
vendored
Normal file
4
docs/.vscode/extensions.json
vendored
Normal file
|
@ -0,0 +1,4 @@
|
|||
{
|
||||
"recommendations": ["astro-build.astro-vscode"],
|
||||
"unwantedRecommendations": []
|
||||
}
|
11
docs/.vscode/launch.json
vendored
Normal file
11
docs/.vscode/launch.json
vendored
Normal file
|
@ -0,0 +1,11 @@
|
|||
{
|
||||
"version": "0.2.0",
|
||||
"configurations": [
|
||||
{
|
||||
"command": "./node_modules/.bin/astro dev",
|
||||
"name": "Development server",
|
||||
"request": "launch",
|
||||
"type": "node-terminal"
|
||||
}
|
||||
]
|
||||
}
|
27
docs/astro.config.mjs
Normal file
27
docs/astro.config.mjs
Normal file
|
@ -0,0 +1,27 @@
|
|||
import { defineConfig } from 'astro/config';
|
||||
import starlight from '@astrojs/starlight';
|
||||
|
||||
// https://astro.build/config
|
||||
export default defineConfig({
|
||||
integrations: [
|
||||
starlight({
|
||||
title: 'My Docs',
|
||||
social: {
|
||||
github: 'https://github.com/withastro/starlight',
|
||||
},
|
||||
sidebar: [
|
||||
{
|
||||
label: 'Guides',
|
||||
items: [
|
||||
// Each item here is one entry in the navigation menu.
|
||||
{ label: 'Example Guide', link: '/guides/example/' },
|
||||
],
|
||||
},
|
||||
{
|
||||
label: 'Reference',
|
||||
autogenerate: { directory: 'reference' },
|
||||
},
|
||||
],
|
||||
}),
|
||||
],
|
||||
});
|
|
@ -1,6 +0,0 @@
|
|||
[book]
|
||||
authors = ["Michael Zhang"]
|
||||
language = "en"
|
||||
multilingual = false
|
||||
src = "src"
|
||||
title = "Panorama Docs"
|
7721
docs/package-lock.json
generated
Normal file
7721
docs/package-lock.json
generated
Normal file
File diff suppressed because it is too large
Load diff
19
docs/package.json
Normal file
19
docs/package.json
Normal file
|
@ -0,0 +1,19 @@
|
|||
{
|
||||
"name": "docs",
|
||||
"type": "module",
|
||||
"version": "0.0.1",
|
||||
"scripts": {
|
||||
"dev": "astro dev",
|
||||
"start": "astro dev",
|
||||
"build": "astro check && astro build",
|
||||
"preview": "astro preview",
|
||||
"astro": "astro"
|
||||
},
|
||||
"dependencies": {
|
||||
"@astrojs/starlight": "^0.24.5",
|
||||
"astro": "^4.10.2",
|
||||
"sharp": "^0.32.5",
|
||||
"@astrojs/check": "^0.7.0",
|
||||
"typescript": "^5.5.2"
|
||||
}
|
||||
}
|
1
docs/public/favicon.svg
Normal file
1
docs/public/favicon.svg
Normal file
|
@ -0,0 +1 @@
|
|||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 128 128"><path fill-rule="evenodd" d="M81 36 64 0 47 36l-1 2-9-10a6 6 0 0 0-9 9l10 10h-2L0 64l36 17h2L28 91a6 6 0 1 0 9 9l9-10 1 2 17 36 17-36v-2l9 10a6 6 0 1 0 9-9l-9-9 2-1 36-17-36-17-2-1 9-9a6 6 0 1 0-9-9l-9 10v-2Zm-17 2-2 5c-4 8-11 15-19 19l-5 2 5 2c8 4 15 11 19 19l2 5 2-5c4-8 11-15 19-19l5-2-5-2c-8-4-15-11-19-19l-2-5Z" clip-rule="evenodd"/><path d="M118 19a6 6 0 0 0-9-9l-3 3a6 6 0 1 0 9 9l3-3Zm-96 4c-2 2-6 2-9 0l-3-3a6 6 0 1 1 9-9l3 3c3 2 3 6 0 9Zm0 82c-2-2-6-2-9 0l-3 3a6 6 0 1 0 9 9l3-3c3-2 3-6 0-9Zm96 4a6 6 0 0 1-9 9l-3-3a6 6 0 1 1 9-9l3 3Z"/><style>path{fill:#000}@media (prefers-color-scheme:dark){path{fill:#fff}}</style></svg>
|
After Width: | Height: | Size: 696 B |
|
@ -1,8 +0,0 @@
|
|||
# Summary
|
||||
|
||||
- [Front](./front.md)
|
||||
- [Nodes](./nodes.md)
|
||||
- [Custom Apps](./custom_apps.md)
|
||||
- [Sync](./sync.md)
|
||||
- [Dream](./dream.md)
|
||||
- [Comparison](./comparison.md)
|
BIN
docs/src/assets/houston.webp
Normal file
BIN
docs/src/assets/houston.webp
Normal file
Binary file not shown.
After Width: | Height: | Size: 96 KiB |
|
@ -1,8 +0,0 @@
|
|||
# Comparison
|
||||
|
||||
From anytype:
|
||||
|
||||
- Knowledgeable about clients
|
||||
- Custom apps by third parties
|
||||
|
||||
From logseq:
|
6
docs/src/content/config.ts
Normal file
6
docs/src/content/config.ts
Normal file
|
@ -0,0 +1,6 @@
|
|||
import { defineCollection } from 'astro:content';
|
||||
import { docsSchema } from '@astrojs/starlight/schema';
|
||||
|
||||
export const collections = {
|
||||
docs: defineCollection({ schema: docsSchema() }),
|
||||
};
|
11
docs/src/content/docs/guides/example.md
Normal file
11
docs/src/content/docs/guides/example.md
Normal file
|
@ -0,0 +1,11 @@
|
|||
---
|
||||
title: Example Guide
|
||||
description: A guide in my new Starlight docs site.
|
||||
---
|
||||
|
||||
Guides lead a user through a specific task they want to accomplish, often with a sequence of steps.
|
||||
Writing a good guide requires thinking about what your users are trying to do.
|
||||
|
||||
## Further reading
|
||||
|
||||
- Read [about how-to guides](https://diataxis.fr/how-to-guides/) in the Diátaxis framework
|
36
docs/src/content/docs/index.mdx
Normal file
36
docs/src/content/docs/index.mdx
Normal file
|
@ -0,0 +1,36 @@
|
|||
---
|
||||
title: Welcome to Starlight
|
||||
description: Get started building your docs site with Starlight.
|
||||
template: splash
|
||||
hero:
|
||||
tagline: Congrats on setting up a new Starlight project!
|
||||
image:
|
||||
file: ../../assets/houston.webp
|
||||
actions:
|
||||
- text: Example Guide
|
||||
link: /guides/example/
|
||||
icon: right-arrow
|
||||
variant: primary
|
||||
- text: Read the Starlight docs
|
||||
link: https://starlight.astro.build
|
||||
icon: external
|
||||
---
|
||||
|
||||
import { Card, CardGrid } from '@astrojs/starlight/components';
|
||||
|
||||
## Next steps
|
||||
|
||||
<CardGrid stagger>
|
||||
<Card title="Update content" icon="pencil">
|
||||
Edit `src/content/docs/index.mdx` to see this page change.
|
||||
</Card>
|
||||
<Card title="Add new content" icon="add-document">
|
||||
Add Markdown or MDX files to `src/content/docs` to create new pages.
|
||||
</Card>
|
||||
<Card title="Configure your site" icon="setting">
|
||||
Edit your `sidebar` and other config in `astro.config.mjs`.
|
||||
</Card>
|
||||
<Card title="Read the docs" icon="open-book">
|
||||
Learn more in [the Starlight Docs](https://starlight.astro.build/).
|
||||
</Card>
|
||||
</CardGrid>
|
11
docs/src/content/docs/reference/example.md
Normal file
11
docs/src/content/docs/reference/example.md
Normal file
|
@ -0,0 +1,11 @@
|
|||
---
|
||||
title: Example Reference
|
||||
description: A reference page in my new Starlight docs site.
|
||||
---
|
||||
|
||||
Reference pages are ideal for outlining how things work in terse and clear terms.
|
||||
Less concerned with telling a story or addressing a specific use case, they should give a comprehensive outline of what you're documenting.
|
||||
|
||||
## Further reading
|
||||
|
||||
- Read [about reference](https://diataxis.fr/reference/) in the Diátaxis framework
|
|
@ -1,64 +0,0 @@
|
|||
# Custom Apps
|
||||
|
||||
<div class="warning">
|
||||
|
||||
**WARNING:** This is documentation for a feature that is in development.
|
||||
|
||||
Almost none of this is implemented and most of it will probably change in the future.
|
||||
|
||||
</div>
|
||||
|
||||
Custom apps allow third parties to develop functionality for panorama.
|
||||
After this rolls out, most of the built-in panorama apps will also be converted into custom apps, and this feature will just be renamed "apps".
|
||||
|
||||
## API
|
||||
|
||||
To develop a custom app, you will need to provide:
|
||||
|
||||
-
|
||||
App metadata in a `manifest.yml`. This contains:
|
||||
|
||||
- App display name.
|
||||
- Version + License.
|
||||
- Description + Keywords.
|
||||
- Compatible panorama versions (TODO).
|
||||
- Authors + Maintainers.
|
||||
- Repository + Issues.
|
||||
- Extra data fields for whatever
|
||||
|
||||
This also includes relationships with other apps. For example:
|
||||
|
||||
- Field read dependencies. If your app needs to read for example `panorama/std/time`, then it needs to list it.
|
||||
- Field write dependencies. This breaks down to:
|
||||
- any: the app is allowed to write to the specified field on any node
|
||||
- owned: the app is allowed to write to the specified field on nodes it owns (**TODO** flesh out app ownership of nodes)
|
||||
- none: the app isn't allowed to write to the specified field
|
||||
|
||||
-
|
||||
List of endpoints and triggers, along with their handlers.
|
||||
|
||||
The handlers take the form `
|
||||
|
||||
## App ownership of nodes
|
||||
|
||||
Apps automatically own nodes they create.
|
||||
|
||||
**TODO:** is multiple ownership allowed?
|
||||
|
||||
## Design notes
|
||||
|
||||
-
|
||||
Maybe it's best to generate the actual db relation names and have their symbolic names be mapped? This will require an extra layer of indirection but it should still make querying be doable in 2 queries.
|
||||
|
||||
For example, the journal app specifies that it wants a `journal` relation. The db generates something like `journal_a41e`, registers that as a mapping for the "journal" app, and all queries will actually involve that name.
|
||||
|
||||
This avoids name conflicts for separate third parties that use the same name for a relation.
|
||||
|
||||
|
||||
## Built-in apps
|
||||
|
||||
### Journal
|
||||
|
||||
### Mail
|
||||
|
||||
### Codetrack
|
|
@ -1,50 +0,0 @@
|
|||
# Dream
|
||||
|
||||
## Custom Apps List
|
||||
|
||||
- File Backup
|
||||
- Object storage
|
||||
- Archivebox like system, bookmarking
|
||||
- Journal
|
||||
- Block-based editor
|
||||
- Embed any node type into journal
|
||||
- Food
|
||||
- Recipe tracker
|
||||
- Grocery list (adds to my todo list)
|
||||
- Meal planner
|
||||
- Food blogging
|
||||
- Health+Fitness
|
||||
- Running progress (incl. saving GPS waypoints)
|
||||
- Workout log for various workouts
|
||||
- Weight tracking
|
||||
- Connect to smartwatch?
|
||||
- Pictures
|
||||
- Face recognition
|
||||
- Map view
|
||||
- Coding
|
||||
- Code tracking like Wakatime
|
||||
- Git forge???
|
||||
- Calendar
|
||||
- Calendly-like appointment booking system
|
||||
- Social
|
||||
- Store people into people app
|
||||
- Email+matrix chat
|
||||
- Video conferencing?
|
||||
- Feed readers / RSS
|
||||
- Media
|
||||
- Music and video hosting / streaming i.e Navidrome
|
||||
- Money tracking
|
||||
- Education
|
||||
- Anki flashcards
|
||||
- Canvas???
|
||||
- Dashboards
|
||||
|
||||
# Features
|
||||
|
||||
- Graph view
|
||||
- Instantly publish anything
|
||||
- Notifications
|
||||
- Full text+OCR search
|
||||
- IFTTT workflows
|
||||
- Multiuser
|
||||
- Google docs like interface for docs / typst
|
2
docs/src/env.d.ts
vendored
Normal file
2
docs/src/env.d.ts
vendored
Normal file
|
@ -0,0 +1,2 @@
|
|||
/// <reference path="../.astro/types.d.ts" />
|
||||
/// <reference types="astro/client" />
|
|
@ -1,6 +0,0 @@
|
|||
# Panorama
|
||||
|
||||
Panorama is a personal information manager.
|
||||
|
||||
- [Repository](https://git.mzhang.io/michael/panorama)
|
||||
- [Issues](https://git.mzhang.io/michael/panorama/issues)
|
|
@ -1,28 +0,0 @@
|
|||
# Nodes
|
||||
|
||||
Everything is organized into nodes.
|
||||
|
||||
Each app (journal, mail, etc.) creates relations from node IDs to their information.
|
||||
|
||||
For example, in a journal, there would be 2 database entries:
|
||||
|
||||
- `node { id: "12345" => type: "panorama/journal/page", created_at: (...), ... }`
|
||||
- `journal { node_id: "12345" => content: "blah blah blah" }`
|
||||
|
||||
When retrieving its contents, a join relation is conducted and all the fields are returned.
|
||||
|
||||
## Field mapping
|
||||
|
||||
In the database, there is a relation mapping field names that the frontend knows about, such as `panorama/journal/page/content` to the actual relation (`journal`) + field name (`content`). These are currently all hard-coded into the migrations, but when custom apps are added they will be able to be registered.
|
||||
|
||||
## Types
|
||||
|
||||
The node type tells the frontend how to render it.
|
||||
|
||||
**TODO:** when custom apps hit, what's the best way to package frontend React code?
|
||||
|
||||
## Synthetic nodes
|
||||
|
||||
These nodes basically only exist on the frontend. For example, `panorama/mail` is a special ID that renders the mail page.
|
||||
|
||||
**TODO:** consider replacing these with short-circuiting the query instead of having special IDs?
|
|
@ -1,20 +0,0 @@
|
|||
# Sync
|
||||
|
||||
<div class="warning">
|
||||
|
||||
**WARNING:** This is documentation for a feature that is in development.
|
||||
|
||||
Almost none of this is implemented and most of it will probably change in the future.
|
||||
|
||||
</div>
|
||||
|
||||
This **only** deals with syncing nodes and files between devices owned by the same person. Permissions are not considered here.
|
||||
|
||||
## Design notes
|
||||
|
||||
-
|
||||
Devices need to have some kind of knowledge of each other's existence. This may not necessarily be exposed to apps, but the thing that's responsible for syncing needs to know which nodes have which files.
|
||||
-
|
||||
Slow internet connections and largely offline usage patterns need to be considered.
|
||||
-
|
||||
**TODO:** does this need to be deeply integrated within the panorama daemon itself or is there a way to expose enough APIs for this to just be an app?
|
3
docs/tsconfig.json
Normal file
3
docs/tsconfig.json
Normal file
|
@ -0,0 +1,3 @@
|
|||
{
|
||||
"extends": "astro/tsconfigs/strict"
|
||||
}
|
Loading…
Reference in a new issue