# 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: in-progress 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. ---