Repository navigation
Glance: the panel's cards run their taps and in-card chat; chat threads keep Mail's account - #278
Merged
Merged
Conversation
ymote
force-pushed
the
fix/glance-panel-taps
branch
from
October 2, 2026 16:14
fa88b7d to
8d99cc4
Compare
ymote
force-pushed
the
fix/glance-panel-taps
branch
from
October 2, 2026 17:07
8d99cc4 to
b1ca381
Compare
…Mail's account The desktop glance panel drew L0 cards with their chips and buttons but ran none of their taps: only the card window did (glance_sheet.rs dispatch_taps), which only a card's toast opens, while every new card opens the panel. A card's buttons and its in-card chat (sys.chat) did nothing there. - glance_card.rs: `LiveCards`, kept by both surfaces. A tile's L0 taps, taken from its own isolate only, run through its card's L0Session, made for the app that published the card: the declared transition, the host's sys.chat write (glance_chat.rs, octosense-l0-chat) and a re-lowering when a tap or the agent's reply moved the card. take_taps now takes one isolate's taps and leaves the others' (two surfaces dispatch), and a swept tile drops its queued taps (a later isolate may get the same heap key). - glance_panel.rs: tiles draw their card as its session has it and dispatch after each event. glance_sheet.rs uses the same path; its redraw now repaints its own area, so a reply that comes later shows. - Chat threads: glance_chat.rs keeps a thread in the account folder of the account the app's agent acts for. contained_account_in read whether the app keeps accounts from its recorded storage block, recorded only when the app opens or its agent is prepared; asked earlier (the demo's seed at startup), it answered `device` for a signed-in Mail. It now reads the manifest's block when none was recorded yet. - octosense-l0-chat: a reply is kept in the thread its message went to, even when the account switched while the agent answered. - glance_chat.rs: HostResponder's doc no longer says Mail has no agent; the canned reply under OCTOSENSE_GLANCE_DEMO=mail stays by design. - desktop README (en, zh-CN): the demo cards work the same in the panel. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ymote
force-pushed
the
fix/glance-panel-taps
branch
from
October 2, 2026 17:14
b1ca381 to
e5d537e
Compare
Contributor
Author
|
Local CI passed on e5d537e ( GitHub would run for this PR: desktop.yml, phone.yml, apps.yml. Merged on this local pass (macOS runner queue); GitHub CI runs on the merge commit on main.
Skipped (these did NOT pass; (!) marks a skip that blocks tools/ci-local-merge.sh):
Notes:
|
ymote
added a commit
that referenced
this pull request
Oct 2, 2026
The phone's glance page drew L0 cards with their chips and fields but ran none of their taps: only the desktop's card window and glance panel kept their cards live (glance_card.rs LiveCards, #278). A card's buttons and its in-card chat (sys.chat) did nothing on a phone. - mobile_pages.rs: GlanceCards, the page's tiles with a LiveCards. A tile's taps, from its own isolate only, run through its card's session, made for the app that published the card, as on the desktop. The feed holds the published GlanceCard itself (its L0 source included) instead of a GlanceCardItem copy without it. - The shell decides what a tap is (GlanceFinger). A card's clicks (NAV calls without text) count only for the lift of a plain tap on that card: no swipe or pull the recognizer took, under 12 pt of travel, not on the shell's own controls, not a finger a long press took. That is the rule the shell's own hits follow. A tap target calls NAV at the end of the event's cycle, so a click is judged on a later event by the last pointer event. Field edits carry the person's text and always run. A tile is tappable only where the page shows it (its cap, above the page indicator and the dock). Page swipes and the page's scroll are unchanged and click no card. - lib.rs: the page's cards get every event as before, plus the finger, read before the shell handles the event. - glance_card.rs: drop_clicks; docs (the phone dispatches now). - desktop README (en, zh-CN): the demo cards work on a phone style's glance page too. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the glance-card mechanics a headless instrument run found (finding B4). No new features.
What was wrong, and why
glance_sheet.rsdispatch_taps). The card window opens only from a card's toast, while every new card opens the panel, so in the panel a card's buttons and its in-card chat (sys.chat) did nothing.glance_chat.rsHostResponder's doc said Mail "has no agent yet", stale since Mail and Calendar agents put cards on the glance screen; assistant pane and glance panel polish #267.desktop/scripts/mail_card_remote.shwaited fornotifications: 2 toast(s). Dropped here: Glance: a card's toast always shows; cards and the panel close #273 (merged) shows a notify card's toast again, stacked left of the open panel, so the wait holds again. The script is unchanged and was not run for this PR.glance_chat.rs,crates/l0-chat/README.md): a thread is kept inapps/<app>/accounts/<account>/chat/, for the account the app's agent acts for (contained::account_of, which the shell answers withapp_storage::lifecycle::contained_account_in). That isdevicefor an app without accounts or with none yet, and otherwise the app's active account. Sodevicefor a signed-in Mail was a bug.contained_account_indecides whether the app keeps accounts from the storage block recorded in memory, which is recorded only when the app opens or its agent is prepared (prepare_agent_with). The demo seeds its thread at startup, beforeagents::start()'s prepare thread records Mail's block. The lookup then read the default ("no accounts") and answereddevice. Once the block was recorded, the same thread would have resolved to the account folder, splitting it in two.Fixes
glance_card.rsLiveCards). The card window and the glance panel keep their L0 cards in aLiveCards. A tile's L0 taps run through its card'sL0Session, which is made for the app that published the card (the glance store's caller). The taps run the declared transition, then the host'ssys.chatwrite (glance_chat::perform→octosense_l0_chat::perform), then a re-lowering when a tap or the agent's reply moved the card. A newer publish of a card starts it over. The panel forgets a card's state when it closes, as the card window does.take_taps(heap)used to take the whole queue and drop every other isolate's taps. That is fine with one dispatching surface, but with two, each would have dropped the other's. It now takes only that isolate's taps. A swept tile drops its queued ones, because a heap key is unique only while its isolate lives.LiveCards. Itsredrawnow repaints its own area (draw_bgis never drawn), so an agent's reply that arrives later shows at once. This matches the fix already made inglance_panel.rs.contained_account_innow reads the manifest's storage block when none has been recorded yet, asprepare_agent_withdoes. The demo's thread is now under Mail's account folder. Inoctosense-l0-chat, a reply is now kept in the thread its message went to. Before, if the account switched while the agent was answering, the reply was written into the new account's thread and the first thread stayedanswering.HostRespondernow says the canned reply underOCTOSENSE_GLANCE_DEMO=mailis there by design (the demo cards and thread are fake data). The canned reply is kept.desktop/README.mdandREADME.zh-CN.md: theOCTOSENSE_GLANCE_DEMO=mailrow now says the demo cards work the same in the glance panel. The root README is not edited.Security properties kept (
crates/l0-chat/README.md, the README's "Cards and questions")GlanceTiles::seat). This PR only adds the dispatch.card.app, the caller recorded at publish, never anything from the tile. Thesys.chatwrite still goes throughoctosense_l0_chat::perform's publisher check andHostResponder.event_payload_originmust beUserInput.Tests
On the Linux build host, at this PR's head (
fa88b7d, onmainat4f73ab34), with its own target dir andCARGO_BUILD_JOBS=16:cargo test --locked -p octosense-l0-chatcargo clippy --locked -p octosense-l0-chat --all-targets --no-deps -- -D warnings,cargo fmt -p octosense-l0-chat --checkphone/:cargo test --locked --features mobile-apps -p octosense-shell glancephone/:... -p octosense-shell app_storagephone/:OCTOS_SHELL_TEST_KERNEL=<octos ae230ce0> cargo test --locked --features mobile-apps -p octosense-shellphone/:OCTOS_SCENARIO_TEST_KERNEL=<octos ae230ce0> ... --lib host_tools::scenario_tests -- --test-threads=1cargo check --locked -p octosense(and--features mobile-apps); fromphone/:cargo check --locked -p octosense-home --features mobile-apps;python3 tools/setup.py --check --cargotools/ci-local.shwas not run.New tests:
glance_card::tests::taps_are_taken_by_the_isolate_that_queued_themglance_card::tests::the_panels_tiles_run_their_own_l0_taps_like_the_card_windowglance_card::tests::a_card_with_buttons_dispatches_from_the_panel_without_the_demoglance_chat::tests::a_cards_thread_is_kept_under_the_account_the_agent_acts_forapp_storage::lifecycle::tests::should_read_the_manifests_block_when_the_account_is_asked_firstoctosense-l0-chata_reply_stays_with_the_account_its_message_went_toInstrument check (headless)
The release desktop shell at
fa88b7dran on the Linux host under a headless weston (--backend=headless --renderer=pixman), driven through makepad's remote instrument with the instrument harness's scripted mock model. No keys were used. Frames come fromMAKEPAD_WRITE_FRAMEBUFFER_PNG, because/gdoes not answer on Linux GL. Chips were located in the frame by colour inside the tile the panel logs, so no click relied on a guessed position.mail.notify; the card opens the panel and is drawn through the live path. A press on it runs no tap (the notice declares no events)OCTOSENSE_GLANCE_DEMO=mail: the cards open the panel; the shipping card's Track runs in the panel (glance panel: os.mail/ups-lamp tap track (applied true, relower true))apps/os.mail/accounts/<hash of Mail's account>/chat/ana-contract.json, with nothing underdevice(before:accounts/device/)tap typing, not re-lowered), Return →tap submit→chat convo recorded; the canned reply follows. The account's thread file holds the seeded exchange, the question and the replyWithout the demo,
mainhas no card with buttons: the shared notice card every app's<app>.notifypublishes (crates/shell/resources/glance/notice.card, #274) and Calendar'sevent.cardandagenda.carddeclare no events. So "a card with buttons dispatches from the panel without the demo" is covered by the shell testa_card_with_buttons_dispatches_from_the_panel_without_the_demo, which publishes the shipping card as a store app with no demo flag and taps Track and Back from its tile's isolate.Overlaps
glance_panel.rs, where Glance: a card's toast always shows; cards and the panel close #273 changed the module doc, thecard_rectstuple, the close and dismiss checks at the top ofhandle_eventand the layout log. This PR adds thelivefield, thelive.bodyline beforeopen_button,live.retainaftertiles.sweep, and the dispatch aftertiles.handle_event, after Glance: a card's toast always shows; cards and the panel close #273's checks. Inglance_card.rs, Glance: a card's toast always shows; cards and the panel close #273 addeddismiss_buttonbesideopen_button; this PR's hunks are the module doc, theNAVqueue,L0Session, the newLiveCards,sweepand the tests. The rebase was clean.notice.card(glance_notice.rs), which declares nosys.chateither; A1 ran on it.Follow-ups
mail.notifypublishes (since System apps: every one has its own agent that can notify #274 the sharednotice.card) declares nosys.chat, and neither do Calendar's cards. Giving an agent's card an in-card chat is a product decision.mobile_pages.rs). Unverified on a device; not changed here.docs/architecture.md§5 (Approvals, "Agent tool calls, not the person's own actions") still says a glance tile has no input and that interactive cards are a PR branch. This has been stale since Interactive glance cards under the publishing app's policy [skip ci] #153.🤖 Generated with Claude Code