98 lines
3.6 KiB
Text
98 lines
3.6 KiB
Text
# TODO List for byteb4rb1e_sphinxcontrib
|
|
|
|
This is a poor-man's issue tracker. I am not primarily a GitHub user so don't
|
|
want to commit to their issue tracking feature, but my primary SVC service
|
|
provider (Bitbucket) only offers paid integration into their issue tracker
|
|
(Jira). I don't have the time (and patience) at the moment to analyze the best
|
|
approach, so this file will have to suffice.
|
|
|
|
It's a very simple concept: Track any issues (features, bugfixes, hotfixes) in
|
|
here, assign a sequential number to it and use that number when branching.
|
|
|
|
I will try to develop a format so that I can parse the file later on, should I
|
|
decide to migrate to a real issue tracker. It's probably going to be Bugzilla,
|
|
but for that my html-theme-ref project needs to stabilize first.
|
|
|
|
## Format Specification
|
|
|
|
The file uses Markdown conventions for formatting headers and other text block
|
|
entitities, but SHOULD NOT be considered a Markdown file. That's why it has no
|
|
definitive file extension.
|
|
|
|
Each issue entry follows a structured format for easier parsing and future
|
|
migration. Issues MUST be **appended** to this file and never moved, to
|
|
preserve Git diffing.
|
|
|
|
### Issue Format
|
|
|
|
```
|
|
|
|
ID: [ISSUE-NUMBER]
|
|
Type: [feature/bugfix/hotfix]
|
|
Title: [Short title]
|
|
Status: [open/in-progress/done/hold/cancelled]
|
|
Priority: [low/medium/high]
|
|
Created: [YYYY-MM-DD]
|
|
Description: [Detailed explanation]
|
|
|
|
---
|
|
```
|
|
|
|
- ISSUE-NUMBERs must be sequential
|
|
- truncation of description must be indentended so that every line starts at the
|
|
same column
|
|
- issues must be started with two LF
|
|
- issues must be terminated with two LF, then `---`
|
|
- issues may have a free-text field (epilog), which must be started with two LF.
|
|
|
|
## Issues
|
|
|
|
ID: 1
|
|
Type: feature
|
|
Title: Experiment with repository layout and build environment
|
|
Status: in-progress
|
|
Priority: low
|
|
Created: 2025-06-06
|
|
Description: Find the best repository layout and build environment for my case
|
|
|
|
---
|
|
|
|
ID: 2
|
|
Type: feature
|
|
Title: Prototype dynamic slide-view directives ("reslide")
|
|
Status: open
|
|
Priority: high
|
|
Created: 2025-06-27
|
|
Description: Implement a Sphinx extension allowing reStructuredText documents to
|
|
be rendered as both linear HTML pages and presentation-style
|
|
slides.
|
|
|
|
The system introduces a non-intrusive layer over standard reST
|
|
content via three main directives:
|
|
|
|
- `.. slide-master::` declares a reusable grid-based layout with
|
|
named areas.
|
|
- `.. slide::` marks a logical section as a slide and references a
|
|
master layout.
|
|
- `.. slide-slot::` maps specific content blocks into areas defined
|
|
by the referenced slide master.
|
|
|
|
Slides are composed in a single reST file without disrupting HTML
|
|
output. During HTML build, a toggle button is injected allowing
|
|
users to switch between document view and presentation view using
|
|
JavaScript and CSS.
|
|
|
|
Additional features include:
|
|
- Fallback or fluid "resize to fit" mode for content overflow
|
|
- Optional pre-build warning system for oversized content
|
|
- Placeholder wireframes for visualizing grid slots (dev mode)
|
|
- Semantic rendering to preserve readability in both views
|
|
|
|
Parsing relies on the sequential nature of reST processing to
|
|
segment slide contents without modifying global tree behavior.
|
|
|
|
This prototype sets up the basic parsing, node registration, and
|
|
HTML translator customization. Styling and JavaScript interactivity
|
|
will be minimal but functional.
|
|
|
|
---
|