gesso-core 0.2.1 → 0.4.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,126 @@
1
1
  # gesso-core
2
2
 
3
+ ## 0.4.0
4
+
5
+ ### Minor Changes
6
+
7
+ - **`DoubleClick`, dispatched after a second Click on the same node.** The pointer
8
+ controller pairs Clicks on the same node within 500 ms and 4 px — the window the
9
+ editing and selection controllers already use for a word — and dispatches
10
+ `DoubleClick` after the second, as the DOM's `dblclick` follows its `click`. A
11
+ press that became a drag or was cancelled spends the pair.
12
+
13
+ `onDoubleClick` on any element; `fireEvent` gains `doubleClick` and
14
+ `contextMenu`.
15
+
16
+ - **A menu opened at a point stays on the screen.** A context menu's point was a
17
+ top and a left and nothing more, so a menu asked for near the bottom or right
18
+ edge opened off the screen.
19
+
20
+ The layout engine gains `anchorPoint`, a point placed beside as an anchor of no
21
+ size would be — the same flip and clamp — and overlays a `point` option that
22
+ uses it. `Menu`'s `at` opens below and to the right of the point, and above or
23
+ to the left when there is no room.
24
+
25
+ Found by a spreadsheet's status bar, whose menu opened below the window.
26
+
27
+ ### Patch Changes
28
+
29
+ - **An absolute box past its containing block keeps its explicit size.** With no
30
+ room left on an axis, the loose constraint an absolute child was measured under
31
+ came out `(0, 0)`, which reads as tight, and a box with an explicit width or
32
+ height was laid out at zero on that axis — where one pixel of room would have
33
+ left it whole.
34
+
35
+ An explicit size is the box's own, as in CSS; the block no longer caps it.
36
+
37
+ - **The browser shells post OS file drops.** The `fileDrop` message, its shape and
38
+ the session that turns it into an ordinary drag have existed since drop targets
39
+ did, and nothing posted one: a zone accepting `gesso/files` could be written and
40
+ never reached.
41
+
42
+ `attachFileDrop` is the shell half, shared by `createApp`'s worker shell and
43
+ `createSyncApp`'s single-thread one because it is the same four DOM events
44
+ either way. It answers drags that carry files and no others, prevents the
45
+ default on every `dragover` (which is what tells a browser the drop is wanted)
46
+ and on `drop` (or the tab is replaced by the file), and reads the bytes before
47
+ posting the drop. The worker shell transfers the buffers rather than copying
48
+ them; a drop whose files cannot be read is reported as a leave, so no zone stays
49
+ lit waiting. `GessoRuntime.applyFileDrop` hands the message to the tree's drag
50
+ session.
51
+
52
+ The core half was wrong in a way no spec could have caught: `applyFileDrop` began
53
+ a drag with the files of `enter` and, on `drop`, only moved it, so a zone
54
+ received the payload the drag started with. A browser lets a page see the _types_
55
+ of dragged files and nothing else until they are let go, so that payload has
56
+ empty names and no bytes — every file dropped from a desktop would have arrived
57
+ unopenable. The spec that covered it sent the same files on both phases, which is
58
+ the one shape a browser never produces. It now sends what one does.
59
+
60
+ ## 0.3.0
61
+
62
+ ### Minor Changes
63
+
64
+ - 025321a: **`fanOut`, for when every node wants its own slice.** One source, N things on
65
+ screen, each reading one part of it: a grid, a timeline, a log viewer all arrive
66
+ at this shape, and the natural spelling does not scale. A pipe per slice runs N
67
+ pipelines on every emission whatever changed, and RxJS removes an observer from a
68
+ Subject by scanning its list, so tearing down a window of N is quadratic.
69
+
70
+ `fanOut(source, read, { initial })` holds one subscription for the whole registry
71
+ and hands out a stable cell per key. Its `changed` hint is where a frame is won: a
72
+ source that knows which keys a patch touched reads only those. Ten thousand live
73
+ keys, measured against a pipe per key: mount 29.8 ms to 10.7 ms, teardown 9.7 ms
74
+ to 3.7 ms, and one key changing 2.2 ms to 0.1 ms.
75
+
76
+ Reach for it when N is large _and each emission touches few of them_. A source
77
+ that republishes its whole window on every scroll gets the cheaper mount and
78
+ teardown and nothing from `changed`, because every key really did change.
79
+
80
+ It compares by reference where `select` and `derive` compare by content, which is
81
+ the opposite default for the opposite reason: those run once per emission and this
82
+ runs once per live key per emission. And a registry that has grown past a couple
83
+ of thousand keys having released none of them says so once, because `release` is
84
+ the caller's and forgetting it is the one thing here that goes wrong silently.
85
+
86
+ **`tabStop`, which is `tabindex="-1"`.** Focusable, reachable by a press and by
87
+ `focus()`, skipped by the Tab cycle. `focusable` only ever answered "may this node
88
+ hold focus", which is the wrong question for a container: `UiFocusManager.settleScope`
89
+ blurred when a scope held nothing focusable, so a `Dialog` whose content is a
90
+ sentence handed the keyboard to nothing and could not be dismissed with Escape.
91
+ `settleScope` now falls back to the scope root before blurring, and `Dialog` sets
92
+ `focusable: true, tabStop: false` on its body. Both halves are needed and neither
93
+ is enough alone.
94
+
95
+ **`borders()`, a border per edge, as paint.** `borderWidth` is one number and
96
+ `borderColor` one colour, so a node could not have a heavy bottom edge and a
97
+ hairline top. A border here is paint-only and a decoration is already a coloured
98
+ rectangle in the node's own paint pass, so four edges are four draw instances and
99
+ no extra nodes. `DecorationBox` gains `right` and `bottom` to put them: any two of
100
+ near edge, size and far edge fix an axis, which is CSS's rule for an absolutely
101
+ positioned box, and the only one that can express a side edge spanning between two
102
+ horizontal ones.
103
+
104
+ **`menuBarStep`, a menu bar's keyboard, as a peer of `Menu`.** `Menu` traps focus,
105
+ which is right for a popup opened by a button and wrong for a bar: with focus in
106
+ the panel, ArrowLeft cannot reach the bar to move to the menu next door, and that
107
+ is most of what makes a bar a bar. A pure function, generic in the command type,
108
+ that returns null for a key it does not claim, so a bar can still be tabbed out of.
109
+
110
+ ### Patch Changes
111
+
112
+ - 025321a: **A finger can scroll a surface on both of its axes.** `UiTouchScroller` picked one
113
+ axis per container from its flex direction, exactly as `UiWheelController` did
114
+ before it was fixed, and dropped the other. So a viewport whose content overflows
115
+ in both directions — a spreadsheet's, which is one `ScrollView` over content wider
116
+ and taller than itself — could not be dragged sideways at all.
117
+
118
+ Each axis is now asked separately whether the container has room, through a
119
+ `hasScrollRoom` the wheel and the touch paths share rather than write twice, so
120
+ the two cannot drift on which container takes a gesture. A fling coasts per axis
121
+ and each axis passes the threshold on its own, so a diagonal throw coasts on both
122
+ and a vertical one does not drift sideways by whatever the thumb happened to do.
123
+
3
124
  ## 0.2.1
4
125
 
5
126
  ## 0.2.0