mirror of
https://github.com/lrnselfreliance/wrolpi.git
synced 2026-10-26 19:01:39 -04:00
Create your own off-grid library
https://wrolpi.org
67c3afbec9
* review: the 375px phone this fix had not been measured on Answers the five findings on #660. * Recurring's four fixed columns wanted 416px between them, so at 375px the URL column got exactly 0 and the table overflowed again -- the same bug as before, moved down from 540px. Widths are phone-first now, in col-* classes, widening at the tablet breakpoint. * The in-progress button in Completed At carried "5 MBps / 3m44s" -- 169-188px measured, against 124px of column. It shows the percent; the modal it opens already lists speed, ETA and bytes, and the full text is on the button's title. * The select column was 2.5em: 16.5px of content for a 22px checkbox, which hung into the URL column. 3em holds the checkbox and its padding. * The Cypress fixtures were a raw <table>, so tableLayout would read 'fixed' even with the selector that loses to Mantine -- the test could not fail for the reason it claimed. They mount SortableTable, Table.HeaderCell onSort and a real Checkbox now, and the header check measures the text rather than skipping cells with no element child. * Comments trimmed to what cannot be recovered from the code. Fixing the first surfaced one more: once URL became the small column, its own header overran -- "URL" and its arrow need 72px against 58 -- and a single word cannot wrap. A header is clipped by its column as a last resort. Measured at 375px: once 46/58/123/146, recurring 44/100/104/57/69, nothing overflowing. 69 suites / 1214 jest tests pass. The Cypress tests here are NOT verified: the component runner does not start in this repo (see the separate cypress investigation), so every layout claim above rests on direct measurement in Chrome, not on that suite. * review: the 375px phone this fix had not been measured on Answers the five findings on #660, and now runs against a component suite that can actually execute (#661). * Recurring's four fixed columns wanted 416px between them, so at 375px the URL got exactly 0 and the table overflowed -- the same bug as before, moved down from 540px. Widths are phone-first now, in col-* classes, widening at the tablet breakpoint. * The in-progress button in Completed At carried "5 MBps / 3m44s", 169-188px against 124px of column. It shows the percent; the modal it opens already lists speed, ETA and bytes, and the full text is on the button's title. * The select column was 2.5em: 16.5px of content for a 22px checkbox, which hung into the URL column. 3em holds the checkbox and its padding. * The fixtures were a raw <table>, so tableLayout read 'fixed' even with the selector that loses to Mantine -- the test could not fail for the reason it claimed. They mount SortableTable, Table.HeaderCell onSort and a real Checkbox now. * Comments trimmed to what cannot be recovered from the code. Two defects the restored suite caught, neither of them findable before it ran: * The elastic URL column ends up narrower than its own header -- "URL" and its arrow need 72px against 58 -- and one word cannot wrap, so the column clips. A sized column must fit its label; only the elastic one may clip. That is what the header test asserts, per kind of column, rather than measuring text and calling it the label: the first version measured the text alone, missed the sort arrow, and passed while the button overran by 14px. * Recurring's Control column was 4.5em, 70px of content for a 78px "Control". Sized for the word rather than the button it holds: 5.2em. At 375px: once 46/58/123/146, recurring 33/100/104/57/80, nothing overflowing and no sized header clipped. The URL column there is 33px -- the accepted trade for keeping every column on a phone. 336 component tests pass, 69 suites / 1214 jest tests pass, npm run build is clean. * review: a header assertion that stopped at the padding box Three findings on #662. * The sized-header check compared scrollWidth to clientWidth, which is the padding box, so a label could overflow its content box into the padding and pass -- the same class of miss the 4.5em Control failure was meant to close. It measures the label's longest word (plus the sort arrow, where there is one) against the content box now. That found two more columns tuned to their exact limit and clipping by a pixel: Download Frequency wanted 79.4px of a 78.1px box, Completed At 82.3 of 81.9. Every sized column now has margin over its own label. * SortableTable stopped applying `width`, leaving dead keys at the Tags and Zim call sites. Removed, so a column is sized one way. CollectionTable's `width` is NOT dead -- it converts sixteenths to percentages -- so Channels, Docs, Playlists and Archive keep theirs. * Comments trimmed again: the percent button, the header clip, the ButtonGroup rule and the Cypress helper. 336 component tests pass, 69 suites / 1214 jest tests pass. * ui: a phone header short enough to leave room for the URL Five full-length headers do not fit a phone. Sized so each held its own label, the recurring URL column came out 20px -- narrower than one character and its ellipsis, a column present but carrying nothing. A long header carries both forms and `.label-*` shows one: Freq and Done below the tablet breakpoint, Download Frequency and Completed At above it, where there is room. The mobile widths are sized for the short word. At 375px the URL column goes from 20px to 105px on the recurring table and 54px to 97px on the once table. Nothing overflows, nothing clips, and every column stays. 336 component tests pass, 69 suites / 1214 jest tests pass, npm run build is clean. |
||
|---|---|---|
| .circleci | ||
| .github | ||
| .run | ||
| alembic | ||
| app | ||
| controller | ||
| debian-live-config | ||
| docker | ||
| etc | ||
| modules | ||
| pi-gen | ||
| release | ||
| scripts | ||
| test | ||
| wrolpi | ||
| .coveragerc | ||
| .dockerignore | ||
| .gitignore | ||
| .gitmodules | ||
| .gitpod.yml | ||
| .mcp.json.example | ||
| alembic.ini | ||
| conftest.py | ||
| demo_link.jpg | ||
| docker-compose.yml | ||
| help.sh | ||
| icon.ico | ||
| icon.png | ||
| INSTALL.md | ||
| install.sh | ||
| join_discord.png | ||
| LICENSE | ||
| main.py | ||
| pytest.ini | ||
| README.md | ||
| repair.sh | ||
| requirements.txt | ||
| test_all.sh | ||
| UPGRADE.md | ||
| upgrade.sh | ||
WROLPi
Create your own off-grid library.
WROLPi is a self-contained collection of software to help you survive the world Without Rule of Law.
WROLPi is intended to be run on a Raspberry Pi with an optional external drive attached. It serves up it's own Wi-Fi network so that any user with a laptop/tablet/phone can connect and use the library created by the maintainer.
Table of Contents
Features
- Videos
- Web Archives
- Maps
- Wikipedia
- File search
- eBooks (EPUB / PDFs)
- Wi-Fi Hotspot
- Universal search
- Food Inventory management
- One-Time pad generator, encrypter/decrypter
- Synchronizer/duplicator
- Food storage calculator
Module features matrix
| Module | View | Search | Download | Project |
|---|---|---|---|---|
| Videos | yes | yes | yes | yt-dlp |
| Web Archives | yes | yes | yes | Singlefile |
| Wikipedia | yes | yes | yes | Kiwix |
| eBooks | yes | yes | planned | EPUB/PDF |
| Map | yes | yes | yes | Protomaps |
| Podcasts/Audio | yes | planned | planned |
Demo
Download
Images are available at wrolpi.org
Try WROLPi!
You can try out WROLPi by running the docker containers.
- Install docker-ce and docker-compose
- Copy the latest WROLPi code.
git clone https://github.com/lrnselfreliance/wrolpi.git
- Change directory into the code base.
cd wrolpi
- Initialize git submodules
git submodule update --init
- Build the containers.
docker-compose build --parallel
- Create volumes.
docker volume create --name=openstreetmap-datadocker volume create --name=openstreetmap-rendered-tiles
- Initialize the database (SQLite in the media directory).
docker-compose run --rm api db upgrade
- Start the docker containers.
docker-compose up
- Browse to WROLPi.
More Docker documentation is available in docker/README.md
Install WROLPi
Full installation instructions are in INSTALL.md. Pick the option that matches your hardware:
- WROLPi Portable (Live USB) — boot a complete WROLPi from a USB stick on any x86 PC or laptop. Nothing is installed to the computer; the first boot creates a persistence partition on the USB so your library, database, and configuration survive reboots.
- Debian 12 — install WROLPi onto an x86 PC or laptop.
- Raspberry Pi — install WROLPi onto a Raspberry Pi with an external drive.
- Docker — run the WROLPi containers on an existing Linux host.
Charter
Guiding Principals
- Storage is cheaper than power.
- Two is one, one is none.
- Run silently.
- Primary, secondary, tertiary.
- Secure as a bookshelf in your home.
Physical properties
- A WROLPi instance should be capable of running with a minimal of hardware:
- Raspberry Pi
- SD card
- External USB hard drive
- Power supply and cables
- Wi-Fi USER device such as a phone, tablet, or laptop.
- A WROLPi instance should consume a minimal amount of electricity during WROL event. It is expected power will be scarce when WROLPi is needed most.
User expectations
- A WROLPi instance should be run and maintained by a person (MAINTAINER) with a moderate amount of Linux and Raspberry Pi experience. It is expected that they should be able to do this using only the documentation on their WROLPi.
Software properties and capabilities
- A WROLPi instance should be able to "factory-reset" itself without any outside services.
- WROLPi should function completely without any internet services.
- A user should have easy access to their data if WROLPi fails:
- For example, a user can watch their videos by navigating a short and intuitive directory structure and opening the video in their preferred video player.
- WROLPi should be self-documented. The UI should contain a tutorial for USERS as well as the MAINTAINER.
- If the UI isn't functional, the code should be documented such that a user can restore functionality.
- WROLPi should favor pre-processing, rather than processing during a WROL event. Such as re-encoding a video, or processing captions. This is to ensure that when a user adds content during non-WROL time, the processing for optimum performance is already done for a WROL event.
Join!
