Adom Shotlog
Public Made by Adomby adom
See the shots your AI never showed you, and know it actually SAW them. adom-shotlog streams every screenshot the AI gathers into a live gallery (webview/pup/browser/phone), reports whether a human is
name: adom-shotlog-child-windows
description: "Capture and display a parent window PLUS its CHILD WINDOWS in shotlog - the owned dropdowns, confirm bubbles, and native dialogs that Adom Desktop returns alongside a window shot, ingested via inject --meta. Use when: injecting a desktop_screenshot_window response, a captured window had a dropdown/dialog open, showing multi-window captures, or asking how child windows render. Trigger words: child windows, parent window, owned windows, owned popups, ownedPopupCount, window array, desktop_screenshot_window array, --meta, coordMap, dropdown capture, dialog capture, multi-window screenshot."
adom-shotlog - parent window + its CHILD WINDOWS (--meta)
A window capture is often not one image. A window that has a dropdown, an
autofill list, a confirm bubble, or a native dialog open is really a parent
window with child windows - separate top-level windows owned by the parent that
a plain PrintWindow of the parent misses entirely.
Adom Desktop surfaces them for you: desktop_screenshot_window {hwnd} returns
the parent image PLUS its child windows as a screenshots[] array, with
ownedPopupCount always present (0 = none). Each child window rides back with its
own hwnd, title, kind (dropdown/dialog/…), rect, and coordMap. This
is AD's generic "find a window's child windows" - no app-specific verb.
Terminology: AD's wire fields are named
ownedPopupCount/screenshots[](Win32 "owned windows"), but conceptually - and in the shotlog UI - these are the parent window's child windows. Don't call them "popups" to the human.
Inject the parent + child windows with --meta
adom-shotlog inject -c CH -d "checkout form with autofill dropdown open" primary.png --meta ad-response.json
--meta takes the FULL desktop_screenshot_window response. shotlog:
- stores coordMap / DPI / screenRect / screenResolution as a sidecar,
- reads each child-window PNG by its
localSafePath, saves it next to the primary (as{primary-stem}__popup{N}.pngon disk - a legacy filename, kept for data compatibility), and attaches it, - derives the original resolution from
origWidth/origHeight(so--metasatisfies the original-resolution rule on its own).
Response shape it reads (extras ignored; needs a primary image + screenshots[]):
{
"shotId": "shot_abc123", "origWidth": 2400, "origHeight": 1520,
"width": 1400, "height": 887,
"coordMap": { "screenRect": {…}, "dpiScale": 2.0, "imageToScreen": {…}, "screenResolution": "2400x1520" },
"ownedPopupCount": 2,
"screenshots": [
{ "localSafePath": "/path/child1.png", "hwnd": 204512, "title": "Address autofill", "kind": "dropdown", "coordMap": {…} },
{ "localSafePath": "/path/child2.png", "hwnd": 204880, "title": "Confirm order", "kind": "dialog", "coordMap": {…} }
]
}
localSafePath must be readable from wherever inject runs.
How child windows DISPLAY - all on the card, no zoom
The human never has to zoom. A shot with child windows renders it all inline:
- a
+N child windowsbadge in the meta row, - a
child windows ▸row under the primary image, showing every child window in ONE horizontal row as a thumbnail, each captionedkind · title · WxH, - an
ⓘ metachip that reveals the coordMap panel (shotId, screenRect, dpiScale, imageToScreen, screen resolution) inline on the card, copyable.
Child-window PNGs are excluded from recovery as standalone entries - they belong to their parent shot.
In a slim right-side panel the primary image can push the
child windows ▸row below the card fold - scroll the card slightly to bring it into view.
Getting a REAL capture (not a mock)
desktop_screenshot_window {hwnd} reports ownedPopupCount for any window; the
child windows only populate when a dropdown/dialog is actually open on that window.
So: open the dropdown/dialog, capture the parent hwnd, and pass the response to
--meta. Plain single-image injects (no --meta) are unchanged - child windows
are additive.
---
name: adom-shotlog-child-windows
description: "Capture and display a parent window PLUS its CHILD WINDOWS in shotlog - the owned dropdowns, confirm bubbles, and native dialogs that Adom Desktop returns alongside a window shot, ingested via `inject --meta`. Use when: injecting a desktop_screenshot_window response, a captured window had a dropdown/dialog open, showing multi-window captures, or asking how child windows render. Trigger words: child windows, parent window, owned windows, owned popups, ownedPopupCount, window array, desktop_screenshot_window array, --meta, coordMap, dropdown capture, dialog capture, multi-window screenshot."
---
# adom-shotlog - parent window + its CHILD WINDOWS (`--meta`)
A window capture is often **not one image**. A window that has a dropdown, an
autofill list, a confirm bubble, or a native dialog open is really a **parent
window with child windows** - separate top-level windows owned by the parent that
a plain `PrintWindow` of the parent misses entirely.
Adom Desktop surfaces them for you: **`desktop_screenshot_window {hwnd}` returns
the parent image PLUS its child windows** as a `screenshots[]` array, with
`ownedPopupCount` always present (0 = none). Each child window rides back with its
own `hwnd`, `title`, `kind` (`dropdown`/`dialog`/…), `rect`, and `coordMap`. This
is AD's generic "find a window's child windows" - no app-specific verb.
> Terminology: AD's wire fields are named `ownedPopupCount` / `screenshots[]`
> (Win32 "owned windows"), but conceptually - and in the shotlog UI - these are
> the parent window's **child windows**. Don't call them "popups" to the human.
## Inject the parent + child windows with `--meta`
```bash
adom-shotlog inject -c CH -d "checkout form with autofill dropdown open" primary.png --meta ad-response.json
```
`--meta` takes the FULL `desktop_screenshot_window` response. shotlog:
- stores coordMap / DPI / screenRect / screenResolution as a sidecar,
- reads each child-window PNG by its `localSafePath`, saves it next to the primary
(as `{primary-stem}__popup{N}.png` on disk - a legacy filename, kept for data
compatibility), and attaches it,
- derives the original resolution from `origWidth/origHeight` (so `--meta` satisfies
the original-resolution rule on its own).
Response shape it reads (extras ignored; needs a primary image + `screenshots[]`):
```json
{
"shotId": "shot_abc123", "origWidth": 2400, "origHeight": 1520,
"width": 1400, "height": 887,
"coordMap": { "screenRect": {…}, "dpiScale": 2.0, "imageToScreen": {…}, "screenResolution": "2400x1520" },
"ownedPopupCount": 2,
"screenshots": [
{ "localSafePath": "/path/child1.png", "hwnd": 204512, "title": "Address autofill", "kind": "dropdown", "coordMap": {…} },
{ "localSafePath": "/path/child2.png", "hwnd": 204880, "title": "Confirm order", "kind": "dialog", "coordMap": {…} }
]
}
```
`localSafePath` must be readable from wherever `inject` runs.
## How child windows DISPLAY - all on the card, no zoom
The human never has to zoom. A shot with child windows renders it all inline:
- a **`+N child windows`** badge in the meta row,
- a **`child windows ▸`** row under the primary image, showing **every child window
in ONE horizontal row** as a thumbnail, each captioned `kind · title · WxH`,
- an **`ⓘ meta`** chip that reveals the coordMap panel (shotId, screenRect,
dpiScale, imageToScreen, screen resolution) **inline on the card**, copyable.
Child-window PNGs are excluded from recovery as standalone entries - they belong
to their parent shot.
> In a slim right-side panel the primary image can push the `child windows ▸` row
> below the card fold - scroll the card slightly to bring it into view.
## Getting a REAL capture (not a mock)
`desktop_screenshot_window {hwnd}` reports `ownedPopupCount` for any window; the
child windows only populate when a dropdown/dialog is actually open on that window.
So: open the dropdown/dialog, capture the parent hwnd, and pass the response to
`--meta`. Plain single-image injects (no `--meta`) are unchanged - child windows
are additive.