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 +121 -0
- package/dist/{CanvasSurface-5dU-U3qQ.js → CanvasSurface-BR7hECHm.js} +1075 -72
- package/dist/CanvasSurface-BR7hECHm.js.map +1 -0
- package/dist/{index-DAdauEn9.d.ts → index-BzXn0Bci.d.ts} +854 -12
- package/dist/index.d.ts +2 -2
- package/dist/index.js +756 -577
- package/dist/index.js.map +1 -1
- package/dist/testing.d.ts +10 -1
- package/dist/testing.js +24 -1
- package/dist/testing.js.map +1 -1
- package/package.json +1 -1
- package/dist/CanvasSurface-5dU-U3qQ.js.map +0 -1
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
|