@formicoidea/labre-ddd-shared 0.41.0 → 0.42.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/LICENSE +384 -0
- package/dist/index.d.ts +0 -1
- package/dist/index.js +0 -1
- package/dist/shared/consts.d.ts +7 -4
- package/dist/shared/consts.js +7 -4
- package/dist/shared/prefabs.d.ts +1 -40
- package/dist/shared/prefabs.js +4 -103
- package/dist/toolbar/icons.d.ts +0 -12
- package/dist/toolbar/icons.js +1 -32
- package/dist/toolbar/senior-buttons.d.ts +11 -0
- package/dist/toolbar/senior-buttons.js +12 -2
- package/package.json +2 -2
- package/dist/shared/legend-auto.d.ts +0 -151
- package/dist/shared/legend-auto.js +0 -134
package/LICENSE
ADDED
|
@@ -0,0 +1,384 @@
|
|
|
1
|
+
# Mozilla Public License Version 2.0
|
|
2
|
+
|
|
3
|
+
Copyright (c) TOEVERYTHING PTE. LTD. and its affiliates.
|
|
4
|
+
|
|
5
|
+
1. Definitions
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
1.1. "Contributor"
|
|
10
|
+
means each individual or legal entity that creates, contributes to
|
|
11
|
+
the creation of, or owns Covered Software.
|
|
12
|
+
|
|
13
|
+
1.2. "Contributor Version"
|
|
14
|
+
means the combination of the Contributions of others (if any) used
|
|
15
|
+
by a Contributor and that particular Contributor's Contribution.
|
|
16
|
+
|
|
17
|
+
1.3. "Contribution"
|
|
18
|
+
means Covered Software of a particular Contributor.
|
|
19
|
+
|
|
20
|
+
1.4. "Covered Software"
|
|
21
|
+
means Source Code Form to which the initial Contributor has attached
|
|
22
|
+
the notice in Exhibit A, the Executable Form of such Source Code
|
|
23
|
+
Form, and Modifications of such Source Code Form, in each case
|
|
24
|
+
including portions thereof.
|
|
25
|
+
|
|
26
|
+
1.5. "Incompatible With Secondary Licenses"
|
|
27
|
+
means
|
|
28
|
+
|
|
29
|
+
(a) that the initial Contributor has attached the notice described
|
|
30
|
+
in Exhibit B to the Covered Software; or
|
|
31
|
+
|
|
32
|
+
(b) that the Covered Software was made available under the terms of
|
|
33
|
+
version 1.1 or earlier of the License, but not also under the
|
|
34
|
+
terms of a Secondary License.
|
|
35
|
+
|
|
36
|
+
1.6. "Executable Form"
|
|
37
|
+
means any form of the work other than Source Code Form.
|
|
38
|
+
|
|
39
|
+
1.7. "Larger Work"
|
|
40
|
+
means a work that combines Covered Software with other material, in
|
|
41
|
+
a separate file or files, that is not Covered Software.
|
|
42
|
+
|
|
43
|
+
1.8. "License"
|
|
44
|
+
means this document.
|
|
45
|
+
|
|
46
|
+
1.9. "Licensable"
|
|
47
|
+
means having the right to grant, to the maximum extent possible,
|
|
48
|
+
whether at the time of the initial grant or subsequently, any and
|
|
49
|
+
all of the rights conveyed by this License.
|
|
50
|
+
|
|
51
|
+
1.10. "Modifications"
|
|
52
|
+
means any of the following:
|
|
53
|
+
|
|
54
|
+
(a) any file in Source Code Form that results from an addition to,
|
|
55
|
+
deletion from, or modification of the contents of Covered
|
|
56
|
+
Software; or
|
|
57
|
+
|
|
58
|
+
(b) any new file in Source Code Form that contains any Covered
|
|
59
|
+
Software.
|
|
60
|
+
|
|
61
|
+
1.11. "Patent Claims" of a Contributor
|
|
62
|
+
means any patent claim(s), including without limitation, method,
|
|
63
|
+
process, and apparatus claims, in any patent Licensable by such
|
|
64
|
+
Contributor that would be infringed, but for the grant of the
|
|
65
|
+
License, by the making, using, selling, offering for sale, having
|
|
66
|
+
made, import, or transfer of either its Contributions or its
|
|
67
|
+
Contributor Version.
|
|
68
|
+
|
|
69
|
+
1.12. "Secondary License"
|
|
70
|
+
means either the GNU General Public License, Version 2.0, the GNU
|
|
71
|
+
Lesser General Public License, Version 2.1, the GNU Affero General
|
|
72
|
+
Public License, Version 3.0, or any later versions of those
|
|
73
|
+
licenses.
|
|
74
|
+
|
|
75
|
+
1.13. "Source Code Form"
|
|
76
|
+
means the form of the work preferred for making modifications.
|
|
77
|
+
|
|
78
|
+
1.14. "You" (or "Your")
|
|
79
|
+
means an individual or a legal entity exercising rights under this
|
|
80
|
+
License. For legal entities, "You" includes any entity that
|
|
81
|
+
controls, is controlled by, or is under common control with You. For
|
|
82
|
+
purposes of this definition, "control" means (a) the power, direct
|
|
83
|
+
or indirect, to cause the direction or management of such entity,
|
|
84
|
+
whether by contract or otherwise, or (b) ownership of more than
|
|
85
|
+
fifty percent (50%) of the outstanding shares or beneficial
|
|
86
|
+
ownership of such entity.
|
|
87
|
+
|
|
88
|
+
2. License Grants and Conditions
|
|
89
|
+
|
|
90
|
+
---
|
|
91
|
+
|
|
92
|
+
2.1. Grants
|
|
93
|
+
|
|
94
|
+
Each Contributor hereby grants You a world-wide, royalty-free,
|
|
95
|
+
non-exclusive license:
|
|
96
|
+
|
|
97
|
+
(a) under intellectual property rights (other than patent or trademark)
|
|
98
|
+
Licensable by such Contributor to use, reproduce, make available,
|
|
99
|
+
modify, display, perform, distribute, and otherwise exploit its
|
|
100
|
+
Contributions, either on an unmodified basis, with Modifications, or
|
|
101
|
+
as part of a Larger Work; and
|
|
102
|
+
|
|
103
|
+
(b) under Patent Claims of such Contributor to make, use, sell, offer
|
|
104
|
+
for sale, have made, import, and otherwise transfer either its
|
|
105
|
+
Contributions or its Contributor Version.
|
|
106
|
+
|
|
107
|
+
2.2. Effective Date
|
|
108
|
+
|
|
109
|
+
The licenses granted in Section 2.1 with respect to any Contribution
|
|
110
|
+
become effective for each Contribution on the date the Contributor first
|
|
111
|
+
distributes such Contribution.
|
|
112
|
+
|
|
113
|
+
2.3. Limitations on Grant Scope
|
|
114
|
+
|
|
115
|
+
The licenses granted in this Section 2 are the only rights granted under
|
|
116
|
+
this License. No additional rights or licenses will be implied from the
|
|
117
|
+
distribution or licensing of Covered Software under this License.
|
|
118
|
+
Notwithstanding Section 2.1(b) above, no patent license is granted by a
|
|
119
|
+
Contributor:
|
|
120
|
+
|
|
121
|
+
(a) for any code that a Contributor has removed from Covered Software;
|
|
122
|
+
or
|
|
123
|
+
|
|
124
|
+
(b) for infringements caused by: (i) Your and any other third party's
|
|
125
|
+
modifications of Covered Software, or (ii) the combination of its
|
|
126
|
+
Contributions with other software (except as part of its Contributor
|
|
127
|
+
Version); or
|
|
128
|
+
|
|
129
|
+
(c) under Patent Claims infringed by Covered Software in the absence of
|
|
130
|
+
its Contributions.
|
|
131
|
+
|
|
132
|
+
This License does not grant any rights in the trademarks, service marks,
|
|
133
|
+
or logos of any Contributor (except as may be necessary to comply with
|
|
134
|
+
the notice requirements in Section 3.4).
|
|
135
|
+
|
|
136
|
+
2.4. Subsequent Licenses
|
|
137
|
+
|
|
138
|
+
No Contributor makes additional grants as a result of Your choice to
|
|
139
|
+
distribute the Covered Software under a subsequent version of this
|
|
140
|
+
License (see Section 10.2) or under the terms of a Secondary License (if
|
|
141
|
+
permitted under the terms of Section 3.3).
|
|
142
|
+
|
|
143
|
+
2.5. Representation
|
|
144
|
+
|
|
145
|
+
Each Contributor represents that the Contributor believes its
|
|
146
|
+
Contributions are its original creation(s) or it has sufficient rights
|
|
147
|
+
to grant the rights to its Contributions conveyed by this License.
|
|
148
|
+
|
|
149
|
+
2.6. Fair Use
|
|
150
|
+
|
|
151
|
+
This License is not intended to limit any rights You have under
|
|
152
|
+
applicable copyright doctrines of fair use, fair dealing, or other
|
|
153
|
+
equivalents.
|
|
154
|
+
|
|
155
|
+
2.7. Conditions
|
|
156
|
+
|
|
157
|
+
Sections 3.1, 3.2, 3.3, and 3.4 are conditions of the licenses granted
|
|
158
|
+
in Section 2.1.
|
|
159
|
+
|
|
160
|
+
3. Responsibilities
|
|
161
|
+
|
|
162
|
+
---
|
|
163
|
+
|
|
164
|
+
3.1. Distribution of Source Form
|
|
165
|
+
|
|
166
|
+
All distribution of Covered Software in Source Code Form, including any
|
|
167
|
+
Modifications that You create or to which You contribute, must be under
|
|
168
|
+
the terms of this License. You must inform recipients that the Source
|
|
169
|
+
Code Form of the Covered Software is governed by the terms of this
|
|
170
|
+
License, and how they can obtain a copy of this License. You may not
|
|
171
|
+
attempt to alter or restrict the recipients' rights in the Source Code
|
|
172
|
+
Form.
|
|
173
|
+
|
|
174
|
+
3.2. Distribution of Executable Form
|
|
175
|
+
|
|
176
|
+
If You distribute Covered Software in Executable Form then:
|
|
177
|
+
|
|
178
|
+
(a) such Covered Software must also be made available in Source Code
|
|
179
|
+
Form, as described in Section 3.1, and You must inform recipients of
|
|
180
|
+
the Executable Form how they can obtain a copy of such Source Code
|
|
181
|
+
Form by reasonable means in a timely manner, at a charge no more
|
|
182
|
+
than the cost of distribution to the recipient; and
|
|
183
|
+
|
|
184
|
+
(b) You may distribute such Executable Form under the terms of this
|
|
185
|
+
License, or sublicense it under different terms, provided that the
|
|
186
|
+
license for the Executable Form does not attempt to limit or alter
|
|
187
|
+
the recipients' rights in the Source Code Form under this License.
|
|
188
|
+
|
|
189
|
+
3.3. Distribution of a Larger Work
|
|
190
|
+
|
|
191
|
+
You may create and distribute a Larger Work under terms of Your choice,
|
|
192
|
+
provided that You also comply with the requirements of this License for
|
|
193
|
+
the Covered Software. If the Larger Work is a combination of Covered
|
|
194
|
+
Software with a work governed by one or more Secondary Licenses, and the
|
|
195
|
+
Covered Software is not Incompatible With Secondary Licenses, this
|
|
196
|
+
License permits You to additionally distribute such Covered Software
|
|
197
|
+
under the terms of such Secondary License(s), so that the recipient of
|
|
198
|
+
the Larger Work may, at their option, further distribute the Covered
|
|
199
|
+
Software under the terms of either this License or such Secondary
|
|
200
|
+
License(s).
|
|
201
|
+
|
|
202
|
+
3.4. Notices
|
|
203
|
+
|
|
204
|
+
You may not remove or alter the substance of any license notices
|
|
205
|
+
(including copyright notices, patent notices, disclaimers of warranty,
|
|
206
|
+
or limitations of liability) contained within the Source Code Form of
|
|
207
|
+
the Covered Software, except that You may alter any license notices to
|
|
208
|
+
the extent required to remedy known factual inaccuracies.
|
|
209
|
+
|
|
210
|
+
3.5. Application of Additional Terms
|
|
211
|
+
|
|
212
|
+
You may choose to offer, and to charge a fee for, warranty, support,
|
|
213
|
+
indemnity or liability obligations to one or more recipients of Covered
|
|
214
|
+
Software. However, You may do so only on Your own behalf, and not on
|
|
215
|
+
behalf of any Contributor. You must make it absolutely clear that any
|
|
216
|
+
such warranty, support, indemnity, or liability obligation is offered by
|
|
217
|
+
You alone, and You hereby agree to indemnify every Contributor for any
|
|
218
|
+
liability incurred by such Contributor as a result of warranty, support,
|
|
219
|
+
indemnity or liability terms You offer. You may include additional
|
|
220
|
+
disclaimers of warranty and limitations of liability specific to any
|
|
221
|
+
jurisdiction.
|
|
222
|
+
|
|
223
|
+
4. Inability to Comply Due to Statute or Regulation
|
|
224
|
+
|
|
225
|
+
---
|
|
226
|
+
|
|
227
|
+
If it is impossible for You to comply with any of the terms of this
|
|
228
|
+
License with respect to some or all of the Covered Software due to
|
|
229
|
+
statute, judicial order, or regulation then You must: (a) comply with
|
|
230
|
+
the terms of this License to the maximum extent possible; and (b)
|
|
231
|
+
describe the limitations and the code they affect. Such description must
|
|
232
|
+
be placed in a text file included with all distributions of the Covered
|
|
233
|
+
Software under this License. Except to the extent prohibited by statute
|
|
234
|
+
or regulation, such description must be sufficiently detailed for a
|
|
235
|
+
recipient of ordinary skill to be able to understand it.
|
|
236
|
+
|
|
237
|
+
5. Termination
|
|
238
|
+
|
|
239
|
+
---
|
|
240
|
+
|
|
241
|
+
5.1. The rights granted under this License will terminate automatically
|
|
242
|
+
if You fail to comply with any of its terms. However, if You become
|
|
243
|
+
compliant, then the rights granted under this License from a particular
|
|
244
|
+
Contributor are reinstated (a) provisionally, unless and until such
|
|
245
|
+
Contributor explicitly and finally terminates Your grants, and (b) on an
|
|
246
|
+
ongoing basis, if such Contributor fails to notify You of the
|
|
247
|
+
non-compliance by some reasonable means prior to 60 days after You have
|
|
248
|
+
come back into compliance. Moreover, Your grants from a particular
|
|
249
|
+
Contributor are reinstated on an ongoing basis if such Contributor
|
|
250
|
+
notifies You of the non-compliance by some reasonable means, this is the
|
|
251
|
+
first time You have received notice of non-compliance with this License
|
|
252
|
+
from such Contributor, and You become compliant prior to 30 days after
|
|
253
|
+
Your receipt of the notice.
|
|
254
|
+
|
|
255
|
+
5.2. If You initiate litigation against any entity by asserting a patent
|
|
256
|
+
infringement claim (excluding declaratory judgment actions,
|
|
257
|
+
counter-claims, and cross-claims) alleging that a Contributor Version
|
|
258
|
+
directly or indirectly infringes any patent, then the rights granted to
|
|
259
|
+
You by any and all Contributors for the Covered Software under Section
|
|
260
|
+
2.1 of this License shall terminate.
|
|
261
|
+
|
|
262
|
+
5.3. In the event of termination under Sections 5.1 or 5.2 above, all
|
|
263
|
+
end user license agreements (excluding distributors and resellers) which
|
|
264
|
+
have been validly granted by You or Your distributors under this License
|
|
265
|
+
prior to termination shall survive termination.
|
|
266
|
+
|
|
267
|
+
---
|
|
268
|
+
|
|
269
|
+
- *
|
|
270
|
+
- 6. Disclaimer of Warranty \*
|
|
271
|
+
- ------------------------- \*
|
|
272
|
+
- *
|
|
273
|
+
- Covered Software is provided under this License on an "as is" \*
|
|
274
|
+
- basis, without warranty of any kind, either expressed, implied, or \*
|
|
275
|
+
- statutory, including, without limitation, warranties that the \*
|
|
276
|
+
- Covered Software is free of defects, merchantable, fit for a \*
|
|
277
|
+
- particular purpose or non-infringing. The entire risk as to the \*
|
|
278
|
+
- quality and performance of the Covered Software is with You. \*
|
|
279
|
+
- Should any Covered Software prove defective in any respect, You \*
|
|
280
|
+
- (not any Contributor) assume the cost of any necessary servicing, \*
|
|
281
|
+
- repair, or correction. This disclaimer of warranty constitutes an \*
|
|
282
|
+
- essential part of this License. No use of any Covered Software is \*
|
|
283
|
+
- authorized under this License except under this disclaimer. \*
|
|
284
|
+
- *
|
|
285
|
+
|
|
286
|
+
---
|
|
287
|
+
|
|
288
|
+
---
|
|
289
|
+
|
|
290
|
+
- *
|
|
291
|
+
- 7. Limitation of Liability \*
|
|
292
|
+
- -------------------------- \*
|
|
293
|
+
- *
|
|
294
|
+
- Under no circumstances and under no legal theory, whether tort \*
|
|
295
|
+
- (including negligence), contract, or otherwise, shall any \*
|
|
296
|
+
- Contributor, or anyone who distributes Covered Software as \*
|
|
297
|
+
- permitted above, be liable to You for any direct, indirect, \*
|
|
298
|
+
- special, incidental, or consequential damages of any character \*
|
|
299
|
+
- including, without limitation, damages for lost profits, loss of \*
|
|
300
|
+
- goodwill, work stoppage, computer failure or malfunction, or any \*
|
|
301
|
+
- and all other commercial damages or losses, even if such party \*
|
|
302
|
+
- shall have been informed of the possibility of such damages. This \*
|
|
303
|
+
- limitation of liability shall not apply to liability for death or \*
|
|
304
|
+
- personal injury resulting from such party's negligence to the \*
|
|
305
|
+
- extent applicable law prohibits such limitation. Some \*
|
|
306
|
+
- jurisdictions do not allow the exclusion or limitation of \*
|
|
307
|
+
- incidental or consequential damages, so this exclusion and \*
|
|
308
|
+
- limitation may not apply to You. \*
|
|
309
|
+
- *
|
|
310
|
+
|
|
311
|
+
---
|
|
312
|
+
|
|
313
|
+
8. Litigation
|
|
314
|
+
|
|
315
|
+
---
|
|
316
|
+
|
|
317
|
+
Any litigation relating to this License may be brought only in the
|
|
318
|
+
courts of a jurisdiction where the defendant maintains its principal
|
|
319
|
+
place of business and such litigation shall be governed by laws of that
|
|
320
|
+
jurisdiction, without reference to its conflict-of-law provisions.
|
|
321
|
+
Nothing in this Section shall prevent a party's ability to bring
|
|
322
|
+
cross-claims or counter-claims.
|
|
323
|
+
|
|
324
|
+
9. Miscellaneous
|
|
325
|
+
|
|
326
|
+
---
|
|
327
|
+
|
|
328
|
+
This License represents the complete agreement concerning the subject
|
|
329
|
+
matter hereof. If any provision of this License is held to be
|
|
330
|
+
unenforceable, such provision shall be reformed only to the extent
|
|
331
|
+
necessary to make it enforceable. Any law or regulation which provides
|
|
332
|
+
that the language of a contract shall be construed against the drafter
|
|
333
|
+
shall not be used to construe this License against a Contributor.
|
|
334
|
+
|
|
335
|
+
10. Versions of the License
|
|
336
|
+
|
|
337
|
+
---
|
|
338
|
+
|
|
339
|
+
10.1. New Versions
|
|
340
|
+
|
|
341
|
+
Mozilla Foundation is the license steward. Except as provided in Section
|
|
342
|
+
10.3, no one other than the license steward has the right to modify or
|
|
343
|
+
publish new versions of this License. Each version will be given a
|
|
344
|
+
distinguishing version number.
|
|
345
|
+
|
|
346
|
+
10.2. Effect of New Versions
|
|
347
|
+
|
|
348
|
+
You may distribute the Covered Software under the terms of the version
|
|
349
|
+
of the License under which You originally received the Covered Software,
|
|
350
|
+
or under the terms of any subsequent version published by the license
|
|
351
|
+
steward.
|
|
352
|
+
|
|
353
|
+
10.3. Modified Versions
|
|
354
|
+
|
|
355
|
+
If you create software not governed by this License, and you want to
|
|
356
|
+
create a new license for such software, you may create and use a
|
|
357
|
+
modified version of this License if you rename the license and remove
|
|
358
|
+
any references to the name of the license steward (except to note that
|
|
359
|
+
such modified license differs from this License).
|
|
360
|
+
|
|
361
|
+
10.4. Distributing Source Code Form that is Incompatible With Secondary
|
|
362
|
+
Licenses
|
|
363
|
+
|
|
364
|
+
If You choose to distribute Source Code Form that is Incompatible With
|
|
365
|
+
Secondary Licenses under the terms of this version of the License, the
|
|
366
|
+
notice described in Exhibit B of this License must be attached.
|
|
367
|
+
|
|
368
|
+
## Exhibit A - Source Code Form License Notice
|
|
369
|
+
|
|
370
|
+
This Source Code Form is subject to the terms of the Mozilla Public
|
|
371
|
+
License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
372
|
+
file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
373
|
+
|
|
374
|
+
If it is not possible or desirable to put the notice in a particular
|
|
375
|
+
file, then You may include the notice in a location (such as a LICENSE
|
|
376
|
+
file in a relevant directory) where a recipient would be likely to look
|
|
377
|
+
for such a notice.
|
|
378
|
+
|
|
379
|
+
You may add additional accurate notices of copyright ownership.
|
|
380
|
+
|
|
381
|
+
## Exhibit B - "Incompatible With Secondary Licenses" Notice
|
|
382
|
+
|
|
383
|
+
This Source Code Form is "Incompatible With Secondary Licenses", as
|
|
384
|
+
defined by the Mozilla Public License, v. 2.0.
|
package/dist/index.d.ts
CHANGED
package/dist/index.js
CHANGED
package/dist/shared/consts.d.ts
CHANGED
|
@@ -223,7 +223,10 @@ export declare const CD_SUBDOMAINS: readonly [{
|
|
|
223
223
|
}];
|
|
224
224
|
export declare const DOT_SIZE = 26;
|
|
225
225
|
export declare const MOVEMENT_COLOR = "#ff3333";
|
|
226
|
-
/**
|
|
227
|
-
|
|
228
|
-
|
|
229
|
-
|
|
226
|
+
/**
|
|
227
|
+
* Label text: ink, family and size. Declared by the legend engine
|
|
228
|
+
* (`@labre/affine-block-surface`), which writes its rows in the very same
|
|
229
|
+
* three values — one declaration, so a DDD caption and the legend line that
|
|
230
|
+
* explains it cannot drift apart.
|
|
231
|
+
*/
|
|
232
|
+
export { LABEL_COLOR, LABEL_FONT, LABEL_FONT_SIZE, } from '@formicoidea/labre-core/blocks/surface';
|
package/dist/shared/consts.js
CHANGED
|
@@ -215,7 +215,10 @@ export const CD_SUBDOMAINS = [
|
|
|
215
215
|
];
|
|
216
216
|
export const DOT_SIZE = 26;
|
|
217
217
|
export const MOVEMENT_COLOR = '#ff3333';
|
|
218
|
-
/**
|
|
219
|
-
|
|
220
|
-
|
|
221
|
-
|
|
218
|
+
/**
|
|
219
|
+
* Label text: ink, family and size. Declared by the legend engine
|
|
220
|
+
* (`@labre/affine-block-surface`), which writes its rows in the very same
|
|
221
|
+
* three values — one declaration, so a DDD caption and the legend line that
|
|
222
|
+
* explains it cannot drift apart.
|
|
223
|
+
*/
|
|
224
|
+
export { LABEL_COLOR, LABEL_FONT, LABEL_FONT_SIZE, } from '@formicoidea/labre-core/blocks/surface';
|
package/dist/shared/prefabs.d.ts
CHANGED
|
@@ -121,44 +121,5 @@ export declare function addMarker(surface: Surface, std: BlockStdScope, cx: numb
|
|
|
121
121
|
role?: string;
|
|
122
122
|
}): string;
|
|
123
123
|
/** A cloud (Big Ball of Mud / general-purpose boundary): a smoothed closed bezier polygon. */
|
|
124
|
-
export declare function addCloud(surface: Surface, std: BlockStdScope, cx: number, cy: number, label?: string): string;
|
|
125
|
-
export interface LegendRow {
|
|
126
|
-
swatch: 'dot' | 'square' | 'line';
|
|
127
|
-
color: string;
|
|
128
|
-
letter?: string;
|
|
129
|
-
label: string;
|
|
130
|
-
/**
|
|
131
|
-
* `line` swatches only: draw the sample as two short segments rather than one
|
|
132
|
-
* bar, so a dashed pattern (Separate Ways, Big Ball of Mud, a Core Domain
|
|
133
|
-
* movement) reads in the legend the way it reads on the board. A legend that
|
|
134
|
-
* showed a solid bar for a dashed link would be telling a small lie about the
|
|
135
|
-
* notation it documents.
|
|
136
|
-
*/
|
|
137
|
-
dashed?: boolean;
|
|
138
|
-
}
|
|
139
|
-
export interface LegendSection {
|
|
140
|
-
title?: string;
|
|
141
|
-
rows: LegendRow[];
|
|
142
|
-
}
|
|
143
|
-
/**
|
|
144
|
-
* How big the box {@link addLegend} would draw for these sections is — without
|
|
145
|
-
* drawing it. The auto-legend needs the height to drop the box bottom-left of a
|
|
146
|
-
* background, and measuring is the only honest way to get it: the box grows with
|
|
147
|
-
* the number of sub-titles and rows, which is exactly what the detection pass
|
|
148
|
-
* decides.
|
|
149
|
-
*/
|
|
150
|
-
export declare function measureLegend(sections: readonly LegendSection[], width?: number): {
|
|
151
|
-
width: number;
|
|
152
|
-
height: number;
|
|
153
|
-
};
|
|
154
|
-
/**
|
|
155
|
-
* A boxed legend: a bordered container with a bold "Legend" title and bold
|
|
156
|
-
* section sub-titles, each row a swatch (dot / square+letter / line) + label.
|
|
157
|
-
* Shared by the Core Domain and Context Map tools. Returns the grouped id.
|
|
158
|
-
*/
|
|
159
|
-
export declare function addLegend(surface: Surface, std: BlockStdScope, x: number, y: number, opts: {
|
|
160
|
-
title: string;
|
|
161
|
-
sections: LegendSection[];
|
|
162
|
-
width?: number;
|
|
163
|
-
}): string;
|
|
124
|
+
export declare function addCloud(surface: Surface, std: BlockStdScope, cx: number, cy: number, label?: string, role?: string): string;
|
|
164
125
|
export {};
|
package/dist/shared/prefabs.js
CHANGED
|
@@ -209,7 +209,7 @@ export function addMarker(surface, std, cx, cy, opts) {
|
|
|
209
209
|
return groupIds(std, ids);
|
|
210
210
|
}
|
|
211
211
|
/** A cloud (Big Ball of Mud / general-purpose boundary): a smoothed closed bezier polygon. */
|
|
212
|
-
export function addCloud(surface, std, cx, cy, label) {
|
|
212
|
+
export function addCloud(surface, std, cx, cy, label, role) {
|
|
213
213
|
const { w, h, fill, stroke } = CLOUD;
|
|
214
214
|
const cloud = surface.addElement({
|
|
215
215
|
type: 'shape',
|
|
@@ -223,111 +223,12 @@ export function addCloud(surface, std, cx, cy, label) {
|
|
|
223
223
|
shapeStyle: ShapeStyle.General,
|
|
224
224
|
roughness: 0,
|
|
225
225
|
xywh: new Bound(cx - w / 2, cy - h / 2, w, h).serialize(),
|
|
226
|
+
// On the POLYGON, never on the group: the polygon is what a relationship
|
|
227
|
+
// binds to and what the legend scan meets.
|
|
228
|
+
...(role ? { role } : {}),
|
|
226
229
|
});
|
|
227
230
|
if (!label)
|
|
228
231
|
return cloud;
|
|
229
232
|
const lbl = addText(surface, cx - w / 2 + 12, cy - LABEL_FONT_SIZE / 2, w - 24, label, NOTATION_NEUTRALS.ink, LABEL_FONT, LABEL_FONT_SIZE);
|
|
230
233
|
return groupIds(std, [cloud, lbl]);
|
|
231
234
|
}
|
|
232
|
-
/**
|
|
233
|
-
* The legend box's geometry, in one place because two callers need it: the one
|
|
234
|
-
* that DRAWS the box and the one that has to know how tall it will be before
|
|
235
|
-
* drawing it (see {@link measureLegend}).
|
|
236
|
-
*/
|
|
237
|
-
const LEGEND_METRICS = {
|
|
238
|
-
DEFAULT_W: 260,
|
|
239
|
-
PAD: 16,
|
|
240
|
-
TITLE_H: 32,
|
|
241
|
-
SUB_H: 26,
|
|
242
|
-
ROW_H: 28,
|
|
243
|
-
/** Swatch side (a `line` swatch is this long). */
|
|
244
|
-
SW: 16,
|
|
245
|
-
};
|
|
246
|
-
/**
|
|
247
|
-
* How big the box {@link addLegend} would draw for these sections is — without
|
|
248
|
-
* drawing it. The auto-legend needs the height to drop the box bottom-left of a
|
|
249
|
-
* background, and measuring is the only honest way to get it: the box grows with
|
|
250
|
-
* the number of sub-titles and rows, which is exactly what the detection pass
|
|
251
|
-
* decides.
|
|
252
|
-
*/
|
|
253
|
-
export function measureLegend(sections, width) {
|
|
254
|
-
const { DEFAULT_W, PAD, TITLE_H, SUB_H, ROW_H } = LEGEND_METRICS;
|
|
255
|
-
let subs = 0;
|
|
256
|
-
let rows = 0;
|
|
257
|
-
for (const s of sections) {
|
|
258
|
-
if (s.title)
|
|
259
|
-
subs++;
|
|
260
|
-
rows += s.rows.length;
|
|
261
|
-
}
|
|
262
|
-
return {
|
|
263
|
-
width: width ?? DEFAULT_W,
|
|
264
|
-
height: PAD * 2 + TITLE_H + subs * SUB_H + rows * ROW_H,
|
|
265
|
-
};
|
|
266
|
-
}
|
|
267
|
-
/**
|
|
268
|
-
* A boxed legend: a bordered container with a bold "Legend" title and bold
|
|
269
|
-
* section sub-titles, each row a swatch (dot / square+letter / line) + label.
|
|
270
|
-
* Shared by the Core Domain and Context Map tools. Returns the grouped id.
|
|
271
|
-
*/
|
|
272
|
-
export function addLegend(surface, std, x, y, opts) {
|
|
273
|
-
const { PAD, TITLE_H, SUB_H, ROW_H, SW } = LEGEND_METRICS;
|
|
274
|
-
const { width: W, height: H } = measureLegend(opts.sections, opts.width);
|
|
275
|
-
const ids = [
|
|
276
|
-
addShape(surface, x, y, W, H, {
|
|
277
|
-
fill: NOTATION_NEUTRALS.cardFill,
|
|
278
|
-
stroke: NOTATION_NEUTRALS.legendBorder,
|
|
279
|
-
strokeWidth: 1.5,
|
|
280
|
-
radius: 8,
|
|
281
|
-
}),
|
|
282
|
-
];
|
|
283
|
-
let cy = y + PAD;
|
|
284
|
-
ids.push(addText(surface, x + PAD, cy, W - PAD * 2, opts.title, LABEL_COLOR, LABEL_FONT, 18, 'left', true));
|
|
285
|
-
cy += TITLE_H;
|
|
286
|
-
for (const sec of opts.sections) {
|
|
287
|
-
if (sec.title) {
|
|
288
|
-
ids.push(addText(surface, x + PAD, cy, W - PAD * 2, sec.title, LABEL_COLOR, LABEL_FONT, 14, 'left', true));
|
|
289
|
-
cy += SUB_H;
|
|
290
|
-
}
|
|
291
|
-
for (const row of sec.rows) {
|
|
292
|
-
const sx = x + PAD;
|
|
293
|
-
const midY = cy + ROW_H / 2;
|
|
294
|
-
if (row.swatch === 'dot') {
|
|
295
|
-
ids.push(addShape(surface, sx, midY - SW / 2, SW, SW, {
|
|
296
|
-
shapeType: 'ellipse',
|
|
297
|
-
fill: row.color,
|
|
298
|
-
stroke: NOTATION_NEUTRALS.ink,
|
|
299
|
-
strokeWidth: 1,
|
|
300
|
-
}));
|
|
301
|
-
}
|
|
302
|
-
else if (row.swatch === 'square') {
|
|
303
|
-
ids.push(addShape(surface, sx, midY - SW / 2, SW, SW, {
|
|
304
|
-
fill: row.color,
|
|
305
|
-
stroke: NOTATION_NEUTRALS.ink,
|
|
306
|
-
strokeWidth: 1,
|
|
307
|
-
radius: 3,
|
|
308
|
-
}));
|
|
309
|
-
if (row.letter)
|
|
310
|
-
ids.push(addText(surface, sx, midY - 8, SW, row.letter, NOTATION_NEUTRALS.ink, LABEL_FONT, 11));
|
|
311
|
-
}
|
|
312
|
-
else if (row.dashed) {
|
|
313
|
-
// Two 6-unit segments with a 4-unit gap: the same 16 units as a solid
|
|
314
|
-
// bar, read as a dash.
|
|
315
|
-
const seg = 6;
|
|
316
|
-
ids.push(addShape(surface, sx, midY - 2, seg, 4, {
|
|
317
|
-
fill: row.color,
|
|
318
|
-
radius: 1,
|
|
319
|
-
}));
|
|
320
|
-
ids.push(addShape(surface, sx + SW - seg, midY - 2, seg, 4, {
|
|
321
|
-
fill: row.color,
|
|
322
|
-
radius: 1,
|
|
323
|
-
}));
|
|
324
|
-
}
|
|
325
|
-
else {
|
|
326
|
-
ids.push(addShape(surface, sx, midY - 2, SW, 4, { fill: row.color, radius: 1 }));
|
|
327
|
-
}
|
|
328
|
-
ids.push(addText(surface, sx + SW + 10, midY - LABEL_FONT_SIZE / 2, W - PAD * 2 - SW - 10, row.label, LABEL_COLOR, LABEL_FONT, 13, 'left'));
|
|
329
|
-
cy += ROW_H;
|
|
330
|
-
}
|
|
331
|
-
}
|
|
332
|
-
return groupIds(std, ids);
|
|
333
|
-
}
|
package/dist/toolbar/icons.d.ts
CHANGED
|
@@ -1,15 +1,3 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* Contextual-toolbar glyph — "generate the legend of what is on this
|
|
3
|
-
* background". One icon for the three DDD backgrounds because it is one
|
|
4
|
-
* gesture; the Core Domain chart has drawn this exact box-and-rows since its
|
|
5
|
-
* legend button shipped, and the two boards now borrow it rather than each
|
|
6
|
-
* redrawing a lookalike.
|
|
7
|
-
*
|
|
8
|
-
* `html` rather than `svg`: a toolbar action's `icon` is rendered as a standalone
|
|
9
|
-
* template, unlike the senior-button glyphs above which are interpolated into an
|
|
10
|
-
* outer `<svg>`.
|
|
11
|
-
*/
|
|
12
|
-
export declare const dddLegendIcon: import("lit-html").TemplateResult<1>;
|
|
13
1
|
/** Senior-button glyph — Event Storming (overlapping stickies). */
|
|
14
2
|
export declare const eventStormingToolbarIcon: import("lit-html").TemplateResult<2>;
|
|
15
3
|
/** Senior-button glyph — Core Domain Chart (axes + bands). */
|
package/dist/toolbar/icons.js
CHANGED
|
@@ -1,36 +1,5 @@
|
|
|
1
1
|
import { NOTATION_NEUTRALS } from '@formicoidea/labre-core/shared/consts';
|
|
2
|
-
import {
|
|
3
|
-
/**
|
|
4
|
-
* Contextual-toolbar glyph — "generate the legend of what is on this
|
|
5
|
-
* background". One icon for the three DDD backgrounds because it is one
|
|
6
|
-
* gesture; the Core Domain chart has drawn this exact box-and-rows since its
|
|
7
|
-
* legend button shipped, and the two boards now borrow it rather than each
|
|
8
|
-
* redrawing a lookalike.
|
|
9
|
-
*
|
|
10
|
-
* `html` rather than `svg`: a toolbar action's `icon` is rendered as a standalone
|
|
11
|
-
* template, unlike the senior-button glyphs above which are interpolated into an
|
|
12
|
-
* outer `<svg>`.
|
|
13
|
-
*/
|
|
14
|
-
export const dddLegendIcon = html `<svg
|
|
15
|
-
width="24"
|
|
16
|
-
height="24"
|
|
17
|
-
viewBox="0 0 24 24"
|
|
18
|
-
fill="none"
|
|
19
|
-
xmlns="http://www.w3.org/2000/svg"
|
|
20
|
-
>
|
|
21
|
-
<rect
|
|
22
|
-
x="3"
|
|
23
|
-
y="4"
|
|
24
|
-
width="18"
|
|
25
|
-
height="16"
|
|
26
|
-
rx="2"
|
|
27
|
-
stroke="currentColor"
|
|
28
|
-
stroke-width="1.6"
|
|
29
|
-
/>
|
|
30
|
-
<circle cx="7" cy="9" r="1.6" fill="currentColor" />
|
|
31
|
-
<circle cx="7" cy="14" r="1.6" fill="currentColor" />
|
|
32
|
-
<path d="M11 9 H18 M11 14 H18" stroke="currentColor" stroke-width="1.4" />
|
|
33
|
-
</svg>`;
|
|
2
|
+
import { svg } from 'lit';
|
|
34
3
|
/** Senior-button glyph — Event Storming (overlapping stickies). */
|
|
35
4
|
export const eventStormingToolbarIcon = svg `<svg width="100%" height="100%" viewBox="0 0 56 56" fill="none" xmlns="http://www.w3.org/2000/svg">
|
|
36
5
|
<rect x="10" y="14" width="22" height="22" rx="2" transform="rotate(-6 21 25)" fill="#F5963B"/>
|
|
@@ -1,4 +1,5 @@
|
|
|
1
1
|
import { EmptyTool } from '@formicoidea/labre-core/gfx/pointer';
|
|
2
|
+
import type { CommandOwner } from '@formicoidea/labre-core/std';
|
|
2
3
|
import { LitElement, type TemplateResult } from 'lit';
|
|
3
4
|
declare const DddSeniorButtonBase_base: typeof LitElement & import("@formicoidea/labre-core/_pkgs/global/utils").Constructor<import("@formicoidea/labre-core/_pkgs/affine-widget-edgeless-toolbar").EdgelessToolbarToolClass>;
|
|
4
5
|
/**
|
|
@@ -16,6 +17,16 @@ export declare abstract class DddSeniorButtonBase extends DddSeniorButtonBase_ba
|
|
|
16
17
|
/** i18n key resolved through the host catalogue; `label` is the fallback. */
|
|
17
18
|
protected abstract labelKey: string;
|
|
18
19
|
protected abstract icon: TemplateResult;
|
|
20
|
+
/** Whose artefacts light this button up while one of them is armed. */
|
|
21
|
+
protected abstract owner: CommandOwner;
|
|
22
|
+
/**
|
|
23
|
+
* Lit while one of THIS framework's artefacts is armed under the cursor, as
|
|
24
|
+
* well as while its menu is open. The menu closes the moment the pointer goes
|
|
25
|
+
* to the board, so without this the ghost would be traceable to no button at
|
|
26
|
+
* all — and Shift+S, which walks that ghost along this framework's row, would
|
|
27
|
+
* read as a keystroke belonging to nothing.
|
|
28
|
+
*/
|
|
29
|
+
private get _armed();
|
|
19
30
|
private _toggleMenu;
|
|
20
31
|
render(): TemplateResult<1>;
|
|
21
32
|
}
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
import { DefaultTool } from '@formicoidea/labre-core/blocks/surface';
|
|
2
2
|
import { EmptyTool } from '@formicoidea/labre-core/gfx/pointer';
|
|
3
3
|
import { translateKey } from '@formicoidea/labre-core/shared/services';
|
|
4
|
-
import { EdgelessToolbarToolMixin } from '@formicoidea/labre-core/widgets/edgeless-toolbar';
|
|
4
|
+
import { armedArtefact, EdgelessToolbarToolMixin, } from '@formicoidea/labre-core/widgets/edgeless-toolbar';
|
|
5
5
|
import { SignalWatcher } from '@formicoidea/labre-core/global/lit';
|
|
6
6
|
import { css, html, LitElement } from 'lit';
|
|
7
7
|
/**
|
|
@@ -53,6 +53,16 @@ export class DddSeniorButtonBase extends EdgelessToolbarToolMixin(SignalWatcher(
|
|
|
53
53
|
--s: 1.07;
|
|
54
54
|
}
|
|
55
55
|
`; }
|
|
56
|
+
/**
|
|
57
|
+
* Lit while one of THIS framework's artefacts is armed under the cursor, as
|
|
58
|
+
* well as while its menu is open. The menu closes the moment the pointer goes
|
|
59
|
+
* to the board, so without this the ghost would be traceable to no button at
|
|
60
|
+
* all — and Shift+S, which walks that ghost along this framework's row, would
|
|
61
|
+
* read as a keystroke belonging to nothing.
|
|
62
|
+
*/
|
|
63
|
+
get _armed() {
|
|
64
|
+
return armedArtefact(this.gfx)?.owner === this.owner;
|
|
65
|
+
}
|
|
56
66
|
_toggleMenu() {
|
|
57
67
|
if (this.popper) {
|
|
58
68
|
this.popper.dispose();
|
|
@@ -70,7 +80,7 @@ export class DddSeniorButtonBase extends EdgelessToolbarToolMixin(SignalWatcher(
|
|
|
70
80
|
? ''
|
|
71
81
|
: translateKey(this.edgeless.std, this.labelKey, this.label)}
|
|
72
82
|
.tooltipOffset=${4}
|
|
73
|
-
.active=${!!this.popper}
|
|
83
|
+
.active=${!!this.popper || this._armed}
|
|
74
84
|
@click=${this._toggleMenu}
|
|
75
85
|
>
|
|
76
86
|
<div class="ddd-root">
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@formicoidea/labre-ddd-shared",
|
|
3
3
|
"description": "Labre ddd-shared — shared building blocks for @formicoidea/labre-core frameworks.",
|
|
4
|
-
"version": "0.
|
|
4
|
+
"version": "0.42.0",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"sideEffects": false,
|
|
7
7
|
"author": "lajola",
|
|
@@ -19,7 +19,7 @@
|
|
|
19
19
|
"dist"
|
|
20
20
|
],
|
|
21
21
|
"dependencies": {
|
|
22
|
-
"@formicoidea/labre-core": "0.
|
|
22
|
+
"@formicoidea/labre-core": "0.42.0",
|
|
23
23
|
"lit": "^3.2.0"
|
|
24
24
|
}
|
|
25
25
|
}
|
|
@@ -1,151 +0,0 @@
|
|
|
1
|
-
import { Bound } from '@formicoidea/labre-core/global/gfx';
|
|
2
|
-
import type { BlockStdScope } from '@formicoidea/labre-core/std';
|
|
3
|
-
import { type GfxController, type RoleDefs, type RoleId } from '@formicoidea/labre-core/std/gfx';
|
|
4
|
-
import { type LegendRow, type LegendSection } from './prefabs.js';
|
|
5
|
-
/**
|
|
6
|
-
* The AUTOMATIC legend, shared by the three DDD backgrounds.
|
|
7
|
-
*
|
|
8
|
-
* Wardley's `createWardleyLegend` is the gesture this replicates — select the
|
|
9
|
-
* background, press one button, get a legend of what is actually drawn on it,
|
|
10
|
-
* dropped bottom-left and grouped so it can be moved and edited like anything
|
|
11
|
-
* else. Two things are deliberately NOT replicated:
|
|
12
|
-
*
|
|
13
|
-
* - **detection is by ROLE, never by `instanceof` or by fill colour.** A role is
|
|
14
|
-
* the semantic identity of an artefact (`framework/std`'s `role.ts`); a shape
|
|
15
|
-
* type is not, and a colour is a restyle away from lying. Reading roles also
|
|
16
|
-
* means a legend and a validation rule agree on what is on the board, because
|
|
17
|
-
* they read the same field;
|
|
18
|
-
* - **the glyphs are the DDD house prefab** ({@link addLegend}), not hand-drawn
|
|
19
|
-
* element-by-element replicas of the artefacts. The three DDD frameworks
|
|
20
|
-
* already document themselves with swatch rows, and a second visual language
|
|
21
|
-
* for the same job would be one too many.
|
|
22
|
-
*
|
|
23
|
-
* A framework contributes nothing but a TABLE: which role puts which row in the
|
|
24
|
-
* legend. Everything else — scanning the perimeter, resolving specialisations,
|
|
25
|
-
* dropping empty sections, placing and grouping the box — happens here once.
|
|
26
|
-
*/
|
|
27
|
-
/**
|
|
28
|
-
* One candidate row: `row` is listed only when `role` — or a role that
|
|
29
|
-
* specialises it — is carried by an element inside the background's perimeter.
|
|
30
|
-
*/
|
|
31
|
-
export interface AutoLegendEntry {
|
|
32
|
-
role: RoleId;
|
|
33
|
-
row: LegendRow;
|
|
34
|
-
/**
|
|
35
|
-
* Match `role` and `role` ALONE, without the specialisation walk.
|
|
36
|
-
*
|
|
37
|
-
* The default — an entry lights up for any of its children — is what a legend
|
|
38
|
-
* usually wants: one "Relation" row covers the twenty-two verbs, one
|
|
39
|
-
* "Sub-domain" row would cover the five kinds. It is also what a validation
|
|
40
|
-
* rule wants, and for the same reason: a statement about a family is a
|
|
41
|
-
* statement about every member of it.
|
|
42
|
-
*
|
|
43
|
-
* A legend sometimes wants the opposite, because it documents what is DRAWN
|
|
44
|
-
* rather than what is meant. EDGY's four base kinds are the case: Content
|
|
45
|
-
* specialises Object, so an entry on `edgy:object` would put an "Object" row
|
|
46
|
-
* on a board where nobody ever dropped a bare Object — the row would name a
|
|
47
|
-
* white square that is nowhere on the diagram. `exact` makes the base and its
|
|
48
|
-
* specialisations two separate statements, so each is listed when, and only
|
|
49
|
-
* when, it is the thing the user actually put down.
|
|
50
|
-
*
|
|
51
|
-
* Reach for it when a row's swatch would be a lie on a board carrying only
|
|
52
|
-
* children — a distinct colour, a distinct shape, a distinct wording. Leave it
|
|
53
|
-
* off when the parent row is a fair summary of the whole family.
|
|
54
|
-
*/
|
|
55
|
-
exact?: boolean;
|
|
56
|
-
/**
|
|
57
|
-
* Static prefix kept literal in front of the role's resolved wording — the
|
|
58
|
-
* Context Map relationship abbreviation ("PS — Partnership"). Absent for
|
|
59
|
-
* every other row, whose label IS the role's own wording and nothing else.
|
|
60
|
-
*/
|
|
61
|
-
labelPrefix?: string;
|
|
62
|
-
}
|
|
63
|
-
export interface AutoLegendSectionSpec {
|
|
64
|
-
/** Sub-title, dropped along with the section when none of its rows appear. */
|
|
65
|
-
title?: string;
|
|
66
|
-
/**
|
|
67
|
-
* i18n key for {@link title}, resolved through the host's catalogue at
|
|
68
|
-
* legend-build time when present. Absent for the sections whose title is
|
|
69
|
-
* generic chrome rather than a framework's own word (`'Legend'`, `'Flow'`…),
|
|
70
|
-
* which this lot leaves as they are.
|
|
71
|
-
*/
|
|
72
|
-
titleKey?: string;
|
|
73
|
-
entries: readonly AutoLegendEntry[];
|
|
74
|
-
}
|
|
75
|
-
export interface AutoLegendSpec {
|
|
76
|
-
/**
|
|
77
|
-
* Box title. Every framework with an automatic legend says "Legend" (PO
|
|
78
|
-
* recette, 26/08/2026: the boxes used to be titled in French, which was the
|
|
79
|
-
* one label in the library that was — identifiers and fallback wordings are
|
|
80
|
-
* English here, and the day a host ships a locale pack it translates a key,
|
|
81
|
-
* not a leftover).
|
|
82
|
-
*/
|
|
83
|
-
title: string;
|
|
84
|
-
/**
|
|
85
|
-
* i18n key for {@link title}, resolved through the host's catalogue at
|
|
86
|
-
* legend-build time — the same mechanism as
|
|
87
|
-
* {@link AutoLegendSectionSpec.titleKey}, one level up. Every framework that
|
|
88
|
-
* says "Legend" reuses `BOARD_LEGEND_TITLE`
|
|
89
|
-
* (`@labre/affine-shared/services`), since it is the SAME word on every
|
|
90
|
-
* board that has one — the three DDD boards, EDGY and C4 alike.
|
|
91
|
-
*/
|
|
92
|
-
titleKey?: string;
|
|
93
|
-
width?: number;
|
|
94
|
-
/**
|
|
95
|
-
* The framework's role vocabulary, so a present role is matched against an
|
|
96
|
-
* entry's role THROUGH the specialisation chain: an entry written on a parent
|
|
97
|
-
* role lists itself as soon as any of its children is on the board — unless
|
|
98
|
-
* it asks for {@link AutoLegendEntry.exact}, which is the whole of the
|
|
99
|
-
* exception.
|
|
100
|
-
*/
|
|
101
|
-
roles: RoleDefs;
|
|
102
|
-
sections: readonly AutoLegendSectionSpec[];
|
|
103
|
-
}
|
|
104
|
-
/**
|
|
105
|
-
* The framework's OWN wording for a role, from the vocabulary that declares it.
|
|
106
|
-
*
|
|
107
|
-
* A legend row about `es:flow` says "Flow" because that is what the role def
|
|
108
|
-
* says it is called — the table below never restates a label the vocabulary
|
|
109
|
-
* already owns, so renaming a role renames its legend row.
|
|
110
|
-
*
|
|
111
|
-
* This is the FALLBACK half only — the English wording a spec bakes in at
|
|
112
|
-
* declaration time, with no `std` in scope to ask a host's catalogue. The
|
|
113
|
-
* catalogue is asked afterwards, once, when the legend is actually drawn: see
|
|
114
|
-
* {@link autoLegendSections}.
|
|
115
|
-
*/
|
|
116
|
-
export declare function roleLabel(roles: RoleDefs, id: RoleId): string;
|
|
117
|
-
/**
|
|
118
|
-
* Every role carried by an element inside `bound`.
|
|
119
|
-
*
|
|
120
|
-
* Neutral elements (no role) contribute nothing, which is the whole
|
|
121
|
-
* compatibility promise: a board drawn before the vocabularies existed produces
|
|
122
|
-
* an empty set and therefore a legend with no rows, exactly like an empty board.
|
|
123
|
-
*/
|
|
124
|
-
export declare function rolesInBound(gfx: GfxController, bound: Bound): Set<RoleId>;
|
|
125
|
-
/**
|
|
126
|
-
* The sections to draw for a given set of present roles: every entry whose role
|
|
127
|
-
* is present (directly or through a specialisation, unless the entry asks for
|
|
128
|
-
* {@link AutoLegendEntry.exact}), in declaration order, with empty sections —
|
|
129
|
-
* sub-title included — dropped.
|
|
130
|
-
*
|
|
131
|
-
* When nothing is recognised the result is an EMPTY array, and the caller still
|
|
132
|
-
* draws the box: that is Wardley's behaviour (an empty map yields a framed
|
|
133
|
-
* "Legend" title and no rows), and it is the honest one — a legend of a board
|
|
134
|
-
* with nothing on it lists nothing, rather than inventing the full notation the
|
|
135
|
-
* user has not used.
|
|
136
|
-
*
|
|
137
|
-
* `std` resolves each surviving row's label — and each section's title, where
|
|
138
|
-
* one carries a {@link AutoLegendSectionSpec.titleKey} — through the host's
|
|
139
|
-
* catalogue (see {@link resolveRowLabel}); a spec whose entries carry no
|
|
140
|
-
* `labelKey` at all renders byte-identical to what it always has.
|
|
141
|
-
*/
|
|
142
|
-
export declare function autoLegendSections(present: ReadonlySet<RoleId>, spec: AutoLegendSpec, std: BlockStdScope): LegendSection[];
|
|
143
|
-
/**
|
|
144
|
-
* Build the legend of what is drawn inside `background` and drop it bottom-left
|
|
145
|
-
* of it, grouped and selected.
|
|
146
|
-
*
|
|
147
|
-
* Returns the group id, or `undefined` when there is no surface to draw on.
|
|
148
|
-
*/
|
|
149
|
-
export declare function createAutoLegend(std: BlockStdScope, background: {
|
|
150
|
-
xywh: string;
|
|
151
|
-
}, spec: AutoLegendSpec): string | undefined;
|
|
@@ -1,134 +0,0 @@
|
|
|
1
|
-
import { translateKey } from '@formicoidea/labre-core/shared/services';
|
|
2
|
-
import { Bound } from '@formicoidea/labre-core/global/gfx';
|
|
3
|
-
import { GfxControllerIdentifier, roleIsA, } from '@formicoidea/labre-core/std/gfx';
|
|
4
|
-
import { addLegend, measureLegend, } from './prefabs.js';
|
|
5
|
-
/**
|
|
6
|
-
* The framework's OWN wording for a role, from the vocabulary that declares it.
|
|
7
|
-
*
|
|
8
|
-
* A legend row about `es:flow` says "Flow" because that is what the role def
|
|
9
|
-
* says it is called — the table below never restates a label the vocabulary
|
|
10
|
-
* already owns, so renaming a role renames its legend row.
|
|
11
|
-
*
|
|
12
|
-
* This is the FALLBACK half only — the English wording a spec bakes in at
|
|
13
|
-
* declaration time, with no `std` in scope to ask a host's catalogue. The
|
|
14
|
-
* catalogue is asked afterwards, once, when the legend is actually drawn: see
|
|
15
|
-
* {@link autoLegendSections}.
|
|
16
|
-
*/
|
|
17
|
-
export function roleLabel(roles, id) {
|
|
18
|
-
return roles[id]?.labelFallback ?? id;
|
|
19
|
-
}
|
|
20
|
-
/**
|
|
21
|
-
* Resolve one row's label through the host's catalogue, at legend-BUILD time
|
|
22
|
-
* — the one point in this module that has a `std` to ask.
|
|
23
|
-
*
|
|
24
|
-
* A row's `label` is baked at spec-declaration time (module scope, no `std`)
|
|
25
|
-
* as the exact English text a catalogue-less playground must keep showing —
|
|
26
|
-
* see {@link roleLabel}. Here, if the row's own role carries a `labelKey`, that
|
|
27
|
-
* baked text becomes the FALLBACK argument of `translateKey` rather than the
|
|
28
|
-
* final word: a host with a catalogue entry for the key overrides it, and a
|
|
29
|
-
* host with none gets back the identical string, letter for letter.
|
|
30
|
-
*
|
|
31
|
-
* `labelPrefix` rows (the Context Map relationship abbreviations, "PS —
|
|
32
|
-
* Partnership") are the one case where the row's baked text is not what gets
|
|
33
|
-
* handed to the catalogue: the role's own `labelFallback` is (the abbreviation
|
|
34
|
-
* itself is never a translatable word), and the prefix is stitched back on
|
|
35
|
-
* after translation.
|
|
36
|
-
*/
|
|
37
|
-
function resolveRowLabel(std, roles, entry) {
|
|
38
|
-
const def = roles[entry.role];
|
|
39
|
-
if (!def?.labelKey)
|
|
40
|
-
return entry.row.label;
|
|
41
|
-
if (entry.labelPrefix) {
|
|
42
|
-
const translated = translateKey(std, def.labelKey, def.labelFallback ?? entry.role);
|
|
43
|
-
return `${entry.labelPrefix} — ${translated}`;
|
|
44
|
-
}
|
|
45
|
-
return translateKey(std, def.labelKey, entry.row.label);
|
|
46
|
-
}
|
|
47
|
-
/**
|
|
48
|
-
* Resolve one section's title through the host's catalogue — see
|
|
49
|
-
* {@link resolveRowLabel}. Absent {@link AutoLegendSectionSpec.titleKey} keeps
|
|
50
|
-
* the section's title exactly as declared, unresolved: most section titles are
|
|
51
|
-
* generic chrome ("Legend", "Flow") this lot leaves untranslated.
|
|
52
|
-
*/
|
|
53
|
-
function resolveSectionTitle(std, section) {
|
|
54
|
-
return section.titleKey && section.title !== undefined
|
|
55
|
-
? translateKey(std, section.titleKey, section.title)
|
|
56
|
-
: section.title;
|
|
57
|
-
}
|
|
58
|
-
/**
|
|
59
|
-
* Distance from the background's left edge / bottom edge, in model units.
|
|
60
|
-
* Wardley's numbers, kept identical so the two gestures put the box in the same
|
|
61
|
-
* place relative to their backgrounds.
|
|
62
|
-
*/
|
|
63
|
-
const INSET_X = 50;
|
|
64
|
-
const INSET_BOTTOM = 56;
|
|
65
|
-
/**
|
|
66
|
-
* Every role carried by an element inside `bound`.
|
|
67
|
-
*
|
|
68
|
-
* Neutral elements (no role) contribute nothing, which is the whole
|
|
69
|
-
* compatibility promise: a board drawn before the vocabularies existed produces
|
|
70
|
-
* an empty set and therefore a legend with no rows, exactly like an empty board.
|
|
71
|
-
*/
|
|
72
|
-
export function rolesInBound(gfx, bound) {
|
|
73
|
-
const present = new Set();
|
|
74
|
-
for (const el of gfx.getElementsByBound(bound, { type: 'canvas' })) {
|
|
75
|
-
if (el.role !== undefined)
|
|
76
|
-
present.add(el.role);
|
|
77
|
-
}
|
|
78
|
-
return present;
|
|
79
|
-
}
|
|
80
|
-
/**
|
|
81
|
-
* The sections to draw for a given set of present roles: every entry whose role
|
|
82
|
-
* is present (directly or through a specialisation, unless the entry asks for
|
|
83
|
-
* {@link AutoLegendEntry.exact}), in declaration order, with empty sections —
|
|
84
|
-
* sub-title included — dropped.
|
|
85
|
-
*
|
|
86
|
-
* When nothing is recognised the result is an EMPTY array, and the caller still
|
|
87
|
-
* draws the box: that is Wardley's behaviour (an empty map yields a framed
|
|
88
|
-
* "Legend" title and no rows), and it is the honest one — a legend of a board
|
|
89
|
-
* with nothing on it lists nothing, rather than inventing the full notation the
|
|
90
|
-
* user has not used.
|
|
91
|
-
*
|
|
92
|
-
* `std` resolves each surviving row's label — and each section's title, where
|
|
93
|
-
* one carries a {@link AutoLegendSectionSpec.titleKey} — through the host's
|
|
94
|
-
* catalogue (see {@link resolveRowLabel}); a spec whose entries carry no
|
|
95
|
-
* `labelKey` at all renders byte-identical to what it always has.
|
|
96
|
-
*/
|
|
97
|
-
export function autoLegendSections(present, spec, std) {
|
|
98
|
-
const sections = [];
|
|
99
|
-
for (const section of spec.sections) {
|
|
100
|
-
const rows = section.entries
|
|
101
|
-
.filter(entry => entry.exact
|
|
102
|
-
? present.has(entry.role)
|
|
103
|
-
: [...present].some(role => roleIsA(role, entry.role, spec.roles)))
|
|
104
|
-
.map(entry => ({
|
|
105
|
-
...entry.row,
|
|
106
|
-
label: resolveRowLabel(std, spec.roles, entry),
|
|
107
|
-
}));
|
|
108
|
-
if (rows.length)
|
|
109
|
-
sections.push({ title: resolveSectionTitle(std, section), rows });
|
|
110
|
-
}
|
|
111
|
-
return sections;
|
|
112
|
-
}
|
|
113
|
-
/**
|
|
114
|
-
* Build the legend of what is drawn inside `background` and drop it bottom-left
|
|
115
|
-
* of it, grouped and selected.
|
|
116
|
-
*
|
|
117
|
-
* Returns the group id, or `undefined` when there is no surface to draw on.
|
|
118
|
-
*/
|
|
119
|
-
export function createAutoLegend(std, background, spec) {
|
|
120
|
-
const gfx = std.get(GfxControllerIdentifier);
|
|
121
|
-
const surface = gfx.surface;
|
|
122
|
-
if (!surface)
|
|
123
|
-
return undefined;
|
|
124
|
-
const bound = Bound.deserialize(background.xywh);
|
|
125
|
-
const sections = autoLegendSections(rolesInBound(gfx, bound), spec, std);
|
|
126
|
-
const title = spec.titleKey
|
|
127
|
-
? translateKey(std, spec.titleKey, spec.title)
|
|
128
|
-
: spec.title;
|
|
129
|
-
const { height } = measureLegend(sections, spec.width);
|
|
130
|
-
std.store.captureSync();
|
|
131
|
-
const id = addLegend(surface, std, bound.x + INSET_X, bound.y + bound.h - INSET_BOTTOM - height, { title, sections, width: spec.width });
|
|
132
|
-
gfx.selection.set({ elements: [id], editing: false });
|
|
133
|
-
return id;
|
|
134
|
-
}
|