Module top_edge_reveal 

Pointer intent for chrome that hides along a window’s top edge until the person reaches for it: the decorations of a maximized window (its title, Full screen, Restore and close) and, in a Tilo app that puts its header there, the app’s header row with them as one bar.

A maximized window gives its whole height to the app, so the bar hides at rest and appears over the window’s top edge; the hard part is telling “click something at the top of the app” from “reach the window’s bar”. The rules, in priority order:

1. Only the very top asks for the bar: the reveal band, the top REVEAL_BAND_PX of the window, above every control an app puts in its top row.
2. Transit is not aim: a sample is transit while the pointer moves faster than TRANSIT_SPEED without braking (still above BRAKE_RATIO of its recent peak).
3. Pushing to the edge is intent: braking in the band after a fast climb (from PUSH_TRAVEL_PX below within PUSH_WINDOW, steeper than 45°) shows the bar at once.
4. Otherwise it takes a short rest in the band, DWELL; a pointer coming down from the desktop’s top bar gets no push credit.
5. A click in the band while the bar is hidden belongs to the app, cancelling a pending reveal until the pointer leaves the band.
6. While shown, the bar stays while the pointer settles on it or in the band, or heads for one of its controls (menu aim, lapsing AIM_HOLD after the last confirming sample); an overshoot into the desktop’s top bar gets OVERSHOOT_GRACE to come back.
7. Aimed-at controls don’t move: showing and hiding only fade the bar in place.
8. Keyboard and touch reach it too: TopEdgeReveal::pin until TopEdgeReveal::unpin, or a touch that drags down TOUCH_SWIPE_PX.

The desktop’s own top bar shares this model so the two never fight over the edge: both hidden, approaching the top reveals the top stack together, and while the desktop’s bar shows over the window’s top edge the window’s bar stands below it. Transit, braking and heading come from super::aim::Trajectory. The state is pure: every method takes the instant it reasons about, so pointer paths are tested against a synthetic timeline.

Structs

EdgeGeometry

Where the bar is, as laid out now.

TopEdgeReveal

Reveal state of one top-edge bar. See the module docs.

Constants

AIM_HOLD

How long a shown bar waits for a pointer that stopped heading for one of its controls without arriving. The same hold the tab row uses.

BRAKE_RATIO

A pointer is braking while its speed has fallen to this share of its peak over the last few samples.

DWELL

How long the pointer rests in the band before the bar shows. A little longer than a hover-open dwell: what lies under the band is the app’s.

OVERSHOOT_GRACE

How long a shown bar waits for a pointer that overshot into the desktop’s top bar above it.

PUSH_SPEED

Peak speed a climb must reach to count as a push for the edge.

PUSH_TRAVEL_PX

How far below the band a pushing pointer started, at most PUSH_WINDOW ago.

PUSH_WINDOW

How recent the start of a push must be.

REVEAL_BAND_PX

Height of the band at the window’s top that summons the bar, in logical px. Thinner than the inset any header row keeps above its controls.

TOUCH_EDGE_PX

The band at a display’s top edge a finger swipes down from: wider than the pointer’s REVEAL_BAND_PX, since a finger coming off the bezel lands a few pixels in.

TOUCH_SWIPE_PX

How far a touch that starts in the band drags down to show the bar.

TRANSIT_SPEED

Pointer speed (logical px per ms) above which a sample that is not braking is transit: on its way somewhere else.