grounded
Home items can be dragged to a specific place instead of instant-pinned
Long-pressing an installed application's tile in the drawer SHALL lift that application's icon to follow the finger instead of pinning it immediately, and Home SHALL be revealed underneath while the drag is live. Releasing over an empty grid cell or dock slot SHALL place the item there. Releasing over an already-pinned application SHALL create a new folder containing both. Releasing over an existing folder SHALL add the item to it. Releasing over a Cancel target, or over the area the drawer's own chrome occupied before the drag began, SHALL abandon the drag with no change to Home. Holding the dragged item near the panel's left or right edge for about 500ms SHALL turn Home to the neighboring page, or add a new page when held past the last one.
evidence in this repository scenarios Dragging a drawer app onto an empty cell places it there
- WHEN a person long-presses a drawer application and releases over an empty Home grid cell - THEN that application's icon appears in exactly that cell
Dragging a drawer app onto another app creates a folder
- WHEN a person drags a drawer application and releases it directly on an application already pinned to Home - THEN a folder now occupies that cell, containing both applications
Dragging onto an existing folder joins it
- WHEN a person releases a dragged application directly on a folder already on Home or in the dock - THEN that application becomes a member of the existing folder rather than creating a nested folder
Cancelling a drag changes nothing
- WHEN a person releases a dragged drawer application over the Cancel target - THEN Home's layout is exactly as it was before the drag began
Holding at the edge turns the page mid-drag
- WHEN a person holds a dragged item within the edge zone for about 500ms - THEN Home turns to the neighboring page (or adds a new one past the last page) and the drag continues on the new page
grounded
Rearranging a pinned item on Home follows the same drop rules as a drawer drag
Long-pressing an item already on Home (an application, a folder, or a widget) SHALL enter the same drag as a drawer-originated one, resolved by the same cell/folder/dock/edge-page-switch rules, plus a Remove target that unpins the dragged item from Home without uninstalling it. A page left with nothing pinned to it after a move SHALL be removed automatically, except that Home always keeps at least one page even when it is empty.
evidence in this repository scenarios Rearranging into an empty cell moves the item
- WHEN a person drags a pinned application to an empty cell on a different page - THEN the application now occupies that cell and its former cell is empty
Dragging one pinned app onto another creates a folder
- WHEN a person drags a pinned application directly onto another pinned application - THEN a folder now occupies the target cell, containing both, and the application's former cell is empty
An emptied page disappears
- WHEN a person's last move off a page leaves it with nothing pinned
- THEN that page no longer appears among Home's pages
Dragging a widget moves the whole widget
- WHEN a person long-presses any cell within a multi-cell widget's span and drags it - THEN the entire widget moves as one unit to wherever it is dropped, if its full span fits there
grounded
Cross-page dragging pages fluidly with a visible edge affordance
While a person holds a dragged Home item (an icon, a folder, or a widget) within about 40px of the panel's left or right edge, Home SHALL show a visible themed highlight and a growing arrow at that edge, and SHALL turn to the neighboring page after about 350-400ms of continuous holding there. Continuing to hold at the edge past that first turn SHALL keep turning pages with a shorter repeat delay of about 260ms. Holding at the true last page's right edge past that same dwell SHALL create a brand-new, empty page and slide onto it rather than remaining inert. Every page turn this triggers, and any triggered by a quick horizontal fling below, SHALL animate as a smooth slide, never an instant jump, and the dragged item's own on-panel position SHALL continue following the raw finger position throughout, unaffected by the page transform. Page-count dots SHALL render enlarged while any drag is live. A quick, deliberate horizontal drag motion during a hold (independent of edge proximity) SHALL also turn one page immediately. A multi-cell widget's drag hovering over a target it cannot fit SHALL show a visibly distinct "no room here" highlight instead of the ordinary accepting one.
evidence in this repository scenarios The edge affordance appears before the page turns
- WHEN a person holds a dragged item within the edge zone for less than the first-dwell threshold - THEN a themed edge highlight and arrow are visible, growing toward full, and the page has not yet turned
A held edge drag turns the page, smoothly, under the finger
- WHEN a person holds a dragged item at the panel's right edge past the first-dwell threshold - THEN Home slides to the next page with an eased animation, and the dragged item stays visually under the finger throughout
Continuing to hold keeps paging, faster than the first turn
- WHEN a person keeps holding a dragged item at the edge after the first page turn - THEN each subsequent page turn fires after the shorter repeat delay, not the longer first-dwell delay
Holding at the true last page's edge creates a new page
- WHEN a person holds a dragged item at the right edge of Home's current last page past the dwell threshold - THEN a new, empty page appears and Home slides onto it
A quick fling pages over without waiting for the edge
- WHEN a person makes a quick, deliberate horizontal drag motion during a hold, anywhere on the panel - THEN Home turns one page immediately, without needing to reach an edge or wait out a dwell
A widget dragged somewhere it cannot fit shows "no room"
- WHEN a person drags a multi-cell widget so it hovers over a cell (or cells) already fully occupied by another item of equal or larger span - THEN the drop-target highlight shows the distinct "no room here" styling instead of the ordinary accepting highlight
unverified
Home presents pinned app icons across swipeable pages
why it is unverified daylight readability has not been observed.
Whenever no application is focused and the card overview is not active, the shell SHALL present Home: the current theme wallpaper with a grid of touch-sized pinned application icons, arranged across one or more horizontally swipeable pages. A page swipe SHALL track the finger 1:1, apply momentum on release, and settle to the nearest whole page with an ease-out motion. When more than one page exists, Home SHALL show a row of page-count indicator dots that are visual indicators only and never a tappable control.
evidence in this repository scenarios A person swipes between Home pages
- WHEN Home holds more icons than fit on one page and a person drags horizontally across the grid - THEN the page follows the finger 1:1 during the drag and settles onto the nearest whole page on release, matching whichever page-count dot is lit
A fast flick advances more than the dragged distance
- WHEN a person flicks quickly and releases before the drag alone would cross a page boundary - THEN momentum carries the page to the next page and it settles there, the same coast-then-settle behavior the existing theme carousel and drawer scrolling already use elsewhere in this shell
A slow release settles immediately
- WHEN a person drags partway across a page and releases with negligible velocity - THEN the page settles immediately to whichever page it is nearest, without coasting past it
grounded
A persistent quick-launch dock spans every Home page
Home SHALL show a fixed-position quick-launch dock beneath the icon grid, holding a bounded number of pinned icons that do not move or scroll when the grid pages change.
evidence in this repository scenarios The dock stays put while pages change
- WHEN a person swipes between Home pages - THEN the dock's icons remain in the same screen position and selection throughout the swipe and after it settles
grounded
Apps can be pinned to, unpinned from, and rearranged on Home
A person SHALL be able to add or remove an installed application through its mouse app menu or long-press grab and deliberately drag icons from the drawer to Home or rearrange them between pages and dock slots. A long-press SHALL grab an icon for movement, not open a menu; a deliberate drag SHALL preserve direct manipulation without also activating the app. Rearrangement SHALL provide contextual Done/remove controls, with no permanent navigation chrome. Pinning an already-pinned app SHALL preserve its placement rather than duplicate it.
evidence in this repository scenarios A person pins an app through its menu
- WHEN a person right-clicks a drawer icon and selects Add to Home
- THEN the app is pinned once, without launching it or moving an existing pin
A person moves or removes an icon
- WHEN a person deliberately drags a Home icon in rearrange mode
- THEN it can move between page/dock slots or to the contextual remove target
- AND removing a pin leaves the application installed and reachable in the drawer
unverified
A fresh Home seeds sensible defaults from installed desktop entries
why it is unverified physical fresh-install seeding is not observed; host fixtures are separate proof.
<!-- Grounding: nix/rust-shell-client/src/catalog.rs's installed_apps() is the existing, already-shipped desktop-entry discovery this requirement reuses rather than reimplementing; the specific curated id list is new to this change and is UNVERIFIED against a real fresh-install image. -->
When no saved Home layout exists, the shell SHALL seed Home from the installed desktop-entry catalog with a curated default set (a terminal, a file manager, a text editor, a system monitor, a video player, and Settings), omitting any entry not present on the running image rather than showing a placeholder for it, and SHALL persist the seeded layout immediately so a later boot is stable even if the catalog subsequently changes.
scenarios First boot on a fresh image
- WHEN the shell starts with no previously saved Home state - THEN Home shows the curated default applications that are actually installed on that image, arranged on its first page, and a saved layout file now exists
A default entry is missing from the image
- WHEN one of the curated default applications (for example, a video player) is not installed on the running image - THEN Home's fresh-seed omits it entirely rather than showing a broken or placeholder icon
unverified
Home's layout persists across restarts and reboots
why it is unverified implemented and host-tested in this change; no reboot observation on the physical board exists yet.
Every pin, unpin, rearrange, and page assignment SHALL be written to a layout file under the shell user's XDG state directory, and SHALL be read back and reproduced exactly on the next start of the shell, including after a reboot. An application that was pinned and has since been uninstalled SHALL keep its grid position empty rather than shifting later icons into it, so reinstalling the same application restores its place.
scenarios A rearranged layout survives a restart
- WHEN a person pins, unpins, or rearranges Home icons and the shell process is later restarted - THEN Home reappears with the exact same page contents, dock contents, and page order as before the restart
An uninstalled app's slot is preserved
- WHEN an application pinned to Home is uninstalled and later reinstalled, with no other Home change in between - THEN its icon reappears in the same grid position it occupied before removal
grounded
App icons provide explicit window and desktop actions
groundingright-click New Window accepted in docs/evidence/home-screen/closeout-2026-10-09.md, with previous primary focus and icon-grab acceptance on the exact same installed Rust executable. Native pointer delivery/dismissal and six injected-board action checks remain separate evidence under docs/evidence/home-screen/app-actions/board/.
Home/dock and the shared launcher app-icon path SHALL provide the same menu through secondary click in mouse mode. Long-press SHALL retain the existing icon-grab/rearrange behavior and SHALL NOT open this menu. The menu SHALL offer named supported desktop actions and identified running windows; New Window SHALL bypass primary focus behavior when supported, prefer the desktop entry's new-window action and not appear twice. Single-window apps SHALL NOT be promised an unsupported second window. Menu dismissal SHALL preserve layout, application focus and ordinary pointer/touch ownership.
evidence in this repository scenarios Explicitly open another window
- WHEN a person opens an app icon's menu and chooses supported New Window
- THEN the shell requests a new window through the desktop-entry launch/action path instead of focusing the existing window
Secondary click opens app actions
- WHEN a person right-clicks an icon
- THEN its app menu opens without activating, pinning or moving that app
Long-press remains an icon grab
- WHEN a person holds an icon to move it
- THEN the existing grab/rearrange flow remains available and no app menu opens
Deliberate movement remains a drag
- WHEN an icon contact deliberately moves beyond drag slop
- THEN it takes the supported icon-placement path and cannot also trigger the stationary-hold menu or launch
grounded
Battery - Details graphs the charge over the last 12 hours
The shell SHALL record the battery percentage and whether the battery was charging about once a minute while it runs, and immediately when the charging state changes, to a per-user history file beside the Home layout. Recording SHALL happen whether or not a Battery - Details widget is placed. The file SHALL keep at least the last 24 hours, SHALL survive shell restarts and reboots, and SHALL be pruned so it does not grow without bound. The Battery - Details widget SHALL draw the last 12 hours of recorded percentage as a line graph from 0 to 100 percent. Charging spans SHALL be visually distinct from discharging spans, and spans with no samples for more than 5 minutes SHALL be shown as gaps rather than joined.
evidence in this repository scenarios History survives a reboot
- WHEN the shell recorded samples, the board reboots and the shell starts again - THEN the widget's graph still shows the earlier samples, with a gap for the time the shell was not running
Discharge then charge
- WHEN the history holds a discharge from 90 to 40 percent followed by a charge back to 70 percent - THEN the graph falls and then rises, with the charging part drawn in the charging style
Bad or future samples
- WHEN the history file has an unparsable line or a sample dated after the current time - THEN those samples are ignored and the rest of the graph still draws
No history yet
- WHEN the history has fewer than two samples in the window
- THEN the widget shows its other metrics without a graph line
grounded
Home always comes to rest on a whole page that exists
When a page drag ends without a release, for example a two-finger trackpad pan the shell cancels, Home SHALL settle to the nearest page rather than stop between two. When the number of pages shrinks so that the page in view no longer exists, Home SHALL settle onto the last page that does, including in rearrange mode. At rest, what Home paints and where a press lands SHALL always refer to the same page.
evidence in this repository scenarios Cancelled trackpad pan
- WHEN a two-finger trackpad pan moves Home partway between pages and the shell cancels it - THEN Home settles to the nearest page, and a press on a widget shown there acts on that widget
Last page emptied
- WHEN the only item on the last page is removed - THEN Home settles onto the previous page and its page dots reflect the new count
grounded
The Clock widget's date is readable at every text step
grounding (2026-10-16)clock_date_is_readable_at_every_text_step checks four card sizes at four steps. Native panel captures at 100%, 160% and 200% are in docs/evidence/home-widgets/clock-date/ and docs/evidence/clock-restyle/. The operator judged the restyled clock on glass: "clock lookgs good" (sic). In the restyle the date is drawn at 32 px or more.
Every Clock widget style SHALL draw its date line at no less than 26 px on the panel at the 100% text step. The size SHALL grow in proportion to the Vision text step. The date line SHALL fit within the widget's cell without ellipsizing, shrinking only to fit the cell's width. The time SHALL NOT overlap the date at any step.
scenarios The date at the default step
- WHEN Home shows a Clock widget at the 100% text step - THEN its date line is at least 26 px tall in font size and is shown in full
The date at the largest step
- WHEN Home shows a Clock widget at the 200% text step - THEN its date line is larger than at 100%, unless the cell's width limits it, and neither the date nor the time is clipped or overlapped