JPRO-203 fix disable logic of properties in patternController by vollbrecht-work · Pull Request #742 · ikmdev/komet

vollbrecht-work · 2025-09-10T20:05:13Z

if the user creates a brand new Pattern ( not in database), than he can edit field_order otherwise the field is disabled
if the user add a pattern than he is able to select a data_type otherwise the field is disabled

a full video of the working behaviour is attached in the jira ticket

if the user creates a brand new Pattern ( not in database), than he can edit field_order otherwise the field is disabled if the user add a pattern than he is able to select a data_type otherwise the field is disabled

vollbrecht-work · 2025-09-11T15:27:35Z

the ticket was not clear to what should be all disabled and enabled in what stage. This is now cleared up. No new fields can be added on an existing pattern. I updated the branch and re-based accordingly

carldea

Excellent work!
I like the comments showing the permutations.

…attern-field-purpose-and-meaning-of-a-published-pattern

carldea · 2025-09-11T16:08:51Z

I've updated your branch and will merge.

carldea

Looks good to me!
Thanks @vollbrecht-work

carldea · 2025-09-11T18:53:25Z

I will update the branch and begin the merge.

…attern-field-purpose-and-meaning-of-a-published-pattern

The compose chip painted its own identicon + name and never asked what kind of component it was drawing, so a pattern chip showed no P — the same defect as the navigator row and the drag image, in a third renderer. It now takes the sigil from KonceptSigils, the one place that rule lives. Not converted to KonceptBadge, deliberately, and this is a finding rather than a shortcut: this chip is not a lazy duplicate of the atom. It overrides getBaselineOffset so it seats on a text line inside the RichTextArea, styles inline so it does not depend on a stylesheet reaching it, and scales its label and identicon from the ambient body font (the assistant's font ± control). KonceptBadge does none of the three — it has setIconSize but no label-font API and a fixed small-caps size. Swapping it in today would freeze the chip's text size and break inline baseline seating. Converging this one needs the atom to gain baseline seating, ambient font scaling, and stylesheet independence first. That is a change to a control used across Komet, so it belongs in #742 with its own verification rather than riding along here. Refs: ikmdev/komet#883 Refs: ikmdev/komet#742

…every drag Four defects from one review of the running app. The badge never set an alignment. An HBox defaults to TOP_LEFT, so the small sigil and status glyphs pinned to the top while the taller identicon set the row height — the sigil sat above the name instead of on its midline, and looked unlike every other surface. Now centred, which fixes it everywhere at once. KonceptDragGlyph.install built its glyph from the PublicId alone, so a drag from the assistant chip lost the sigil no matter what the chip rendered. It has the nid in hand and now resolves the kind from it. The pattern navigator row rendered the atom at its inline default, scaled for sitting beside body text, which is far too small for a navigation list. It now sizes from the row's own ambient font. Two patterns read as raw nids. Converting the row to the atom dropped the navigator's own name resolution, whose fallback names the absence of a description; the badge's default falls back to the nid instead. The row supplies the name again, and setConceptName is public so any host with better resolution can do the same. Still unexplained and NOT fixed: the green frame around the drag image from the pattern navigator. No production code sets the glyph border — only a test, which restores it — and kview has no drag styling on that row, so it is not determinable from the source and needs a runtime discriminator. Refs: ikmdev/komet#742 Refs: ikmdev/komet#883

…r the written spec The pattern-navigator drag stayed wrong after converting the row-level drag handler because that handler no longer fires: the badge placed INTO the row is itself a drag source, its press wins, and its constructor installed the legacy snapshot path. The full chain, now determined from source: badge press -> KonceptDragSource.install snapshot -> DragImageMaker flips the :snapshot pseudo-class -> kview's .draggable-node:snapshot rule paints a 4px -Primary-05 border -> rescale to standard height. That is the wide, white, green-framed, soft drag image — the green was never the glyph border and never a drop indicator. The badge now installs its own gesture-time drag: the generated KonceptDragGlyph built from its CURRENT kind, name, and retired state, with the KometClipboard payload. One drag behavior per atom — every badge everywhere, including hosts whose own drag handler the badge shadows, drags the tight, sigil-bearing, 1:1 glyph. The chip drops its now-redundant explicit install. The sigil is now bold in both sizing paths. The normative source is koncept-asciidoc-extension's koncept.css — the stylesheet that renders the written badge-spec table — which declares font-weight bold, mirroring the styles the doc renderer emits. Weight, like glyph and colour, is data every medium agrees on, so it is set in code rather than left to whichever stylesheet loads. Toward the same end: runtime renderers converge on the doc renderer as the executable spec, per the settled KonceptAppearance design. Refs: ikmdev/komet#742 Refs: ikmdev/komet#882 Refs: ikmdev/komet#883

…re on its row Two drag-source gaps from testing the running app. The assistant chips stopped dragging — a regression from moving the chip onto the badge's own drag handling: the chip builds through the two-argument presentation constructor, which is UNKNOWN_NID by design and so installs no drag handler. A new identity-bearing presentation constructor takes the nid the chip already has: a known component drags even without a view, and the presentation-only form stays inert, pinned by test. A concept could not be dragged out of the navigator by grabbing the row. Not a regression — no navigator control changed on this branch — but a gap the pattern side exposed: single-concept drag was gated to the tile's hover select affordance, while a pattern row now drags from anywhere because its badge is the drag source. The whole ConceptTile is now a drag source sharing one beginConceptDrag with the affordance path, so the two gestures cannot drift. The skin's multi-selection filter and the affordance's own filter consume their gestures first; the tile handles exactly the plain row press that previously started nothing. Refs: ikmdev/komet#742 Refs: ikmdev/komet#882

…:32 pentagon to identicon The badge-spec anatomy figures are generated, so their geometry is code: KonceptFigureRenderer draws the identicon-bearing pill with a bold 15px sigil against a 12px name and a 20px pentagon against a 32px identicon. Those two ratios — sigil a quarter larger than the name, pentagon five-eighths of the identicon — are now held by the runtime renderers, replacing my invented 1:1s: the badge derives both from its current name font and identicon size (default, ambient, and small-caps-fallback paths alike), and the drag glyph derives its constants the same way. A conformance test pins the 15:12 ratio at the ratio itself, not at any absolute size. Eyeball check against the published figures agrees (~38px sigil over ~30px name caps in the pattern anatomy, ~0.74 pentagon-to-identicon in the STAMP one, within measurement error of 20:32 = 0.625). One discrepancy surfaced and deliberately not resolved here: the flat k: SVG badge form (KonceptSvgRenderer, no identicon) sets its sigil at the label size, not 15:12. The two document forms disagree, and which one the appearance spec blesses is a KonceptAppearance decision — flagged for #742 rather than silently picked. Refs: ikmdev/komet#742 Refs: ikmdev/komet#883

A chip inside a RichTextArea needed a second press before it would drag: the first press, unconsumed, let the RichTextArea begin a text selection, and only once the chip sat inside a selection did DRAG_DETECTED reach the chip. The tree-block renderer already carried the fix — consume the press so the area never arms selection over a chip, while DRAG_DETECTED still fires — but only for its own chips, which is exactly why transcript and compose chips needed the extra press. The chip factory owns the behavior now, so every embedded chip — transcript inline, compose box, tree blocks — drags on a single press-and-drag, and the tree renderer's local copy is gone. The compose-box consequence is accepted: clicking a chip no longer places the caret on it, which was never meaningful for an atomic token; clicks beside a chip behave as before. The white corner notches on the drag image are a separate finding — the glyph's corners are transparent at the source and the alpha is flattened downstream of setDragView, suspected JavaFX 27-ea — filed as ikmdev/komet#885 rather than worked around here. Refs: ikmdev/komet#742 Refs: ikmdev/komet#885

A pattern dragged anywhere in Komet arrived without its sigil, while the same component rendered as a KonceptBadge showed it — the drag image and the badge disagreed about what the component is. KonceptKind already owns the mapping (which kinds carry a sigil, each one's glyph, colour, accessible name). What was duplicated was the node: KonceptBadge assembled Text + style class + fill + tooltip itself, and KonceptDragGlyph assembled nothing at all. KonceptSigils now builds it, and both renderers come through it, so a sigil cannot come out different depending on where it is drawn. The two renderers have genuinely different mechanics, which the factory takes as a parameter rather than papering over: the badge is a laid-out control the stylesheet reaches and passes size 0; the glyph snapshots into fixed integer geometry in a throwaway scene with NO stylesheet attached, so it sizes the letter explicitly — a CSS-sized glyph would render at the default size there, which is the wrong-magnification half of the report. The nid-bearing entry points resolve the kind, since they have the nid and the view; the PublicId overloads cannot know it and stay bare as before. The cursor anchor now tracks the identicon explicitly instead of the first child, which a leading sigil would otherwise displace. Fixes: #883 Refs: #742 Refs: #882

… atom The row built its own identicon + label and never asked what kind of component it was drawing, so a pattern row could never show its P — the same defect as the drag image, in a second renderer. One atom now renders it: KonceptBadge resolves the identicon, the name, and the component-kind sigil from the nid and the view. This is the first of the three surfaces in the one-atom conversion (#742's charter): a rule added to the atom now reaches this row instead of having to be re-implemented here. The compose chip and the transcript pill still paint their own identicon + text and remain to convert. The badge carries its own identity tooltip, so the separate name tooltip goes with the label it was installed on. Refs: #742 Refs: #883

…every drag Four defects from one review of the running app. The badge never set an alignment. An HBox defaults to TOP_LEFT, so the small sigil and status glyphs pinned to the top while the taller identicon set the row height — the sigil sat above the name instead of on its midline, and looked unlike every other surface. Now centred, which fixes it everywhere at once. KonceptDragGlyph.install built its glyph from the PublicId alone, so a drag from the assistant chip lost the sigil no matter what the chip rendered. It has the nid in hand and now resolves the kind from it. The pattern navigator row rendered the atom at its inline default, scaled for sitting beside body text, which is far too small for a navigation list. It now sizes from the row's own ambient font. Two patterns read as raw nids. Converting the row to the atom dropped the navigator's own name resolution, whose fallback names the absence of a description; the badge's default falls back to the nid instead. The row supplies the name again, and setConceptName is public so any host with better resolution can do the same. Still unexplained and NOT fixed: the green frame around the drag image from the pattern navigator. No production code sets the glyph border — only a test, which restores it — and kview has no drag styling on that row, so it is not determinable from the source and needs a runtime discriminator. Refs: #742 Refs: #883

…r the written spec The pattern-navigator drag stayed wrong after converting the row-level drag handler because that handler no longer fires: the badge placed INTO the row is itself a drag source, its press wins, and its constructor installed the legacy snapshot path. The full chain, now determined from source: badge press -> KonceptDragSource.install snapshot -> DragImageMaker flips the :snapshot pseudo-class -> kview's .draggable-node:snapshot rule paints a 4px -Primary-05 border -> rescale to standard height. That is the wide, white, green-framed, soft drag image — the green was never the glyph border and never a drop indicator. The badge now installs its own gesture-time drag: the generated KonceptDragGlyph built from its CURRENT kind, name, and retired state, with the KometClipboard payload. One drag behavior per atom — every badge everywhere, including hosts whose own drag handler the badge shadows, drags the tight, sigil-bearing, 1:1 glyph. The chip drops its now-redundant explicit install. The sigil is now bold in both sizing paths. The normative source is koncept-asciidoc-extension's koncept.css — the stylesheet that renders the written badge-spec table — which declares font-weight bold, mirroring the styles the doc renderer emits. Weight, like glyph and colour, is data every medium agrees on, so it is set in code rather than left to whichever stylesheet loads. Toward the same end: runtime renderers converge on the doc renderer as the executable spec, per the settled KonceptAppearance design. Refs: #742 Refs: #882 Refs: #883

…re on its row Two drag-source gaps from testing the running app. The assistant chips stopped dragging — a regression from moving the chip onto the badge's own drag handling: the chip builds through the two-argument presentation constructor, which is UNKNOWN_NID by design and so installs no drag handler. A new identity-bearing presentation constructor takes the nid the chip already has: a known component drags even without a view, and the presentation-only form stays inert, pinned by test. A concept could not be dragged out of the navigator by grabbing the row. Not a regression — no navigator control changed on this branch — but a gap the pattern side exposed: single-concept drag was gated to the tile's hover select affordance, while a pattern row now drags from anywhere because its badge is the drag source. The whole ConceptTile is now a drag source sharing one beginConceptDrag with the affordance path, so the two gestures cannot drift. The skin's multi-selection filter and the affordance's own filter consume their gestures first; the tile handles exactly the plain row press that previously started nothing. Refs: #742 Refs: #882

…:32 pentagon to identicon The badge-spec anatomy figures are generated, so their geometry is code: KonceptFigureRenderer draws the identicon-bearing pill with a bold 15px sigil against a 12px name and a 20px pentagon against a 32px identicon. Those two ratios — sigil a quarter larger than the name, pentagon five-eighths of the identicon — are now held by the runtime renderers, replacing my invented 1:1s: the badge derives both from its current name font and identicon size (default, ambient, and small-caps-fallback paths alike), and the drag glyph derives its constants the same way. A conformance test pins the 15:12 ratio at the ratio itself, not at any absolute size. Eyeball check against the published figures agrees (~38px sigil over ~30px name caps in the pattern anatomy, ~0.74 pentagon-to-identicon in the STAMP one, within measurement error of 20:32 = 0.625). One discrepancy surfaced and deliberately not resolved here: the flat k: SVG badge form (KonceptSvgRenderer, no identicon) sets its sigil at the label size, not 15:12. The two document forms disagree, and which one the appearance spec blesses is a KonceptAppearance decision — flagged for #742 rather than silently picked. Refs: #742 Refs: #883

Corrects e63415d, whose analysis was wrong: consuming the press in a bubbling handler on the chip cannot preempt the RichTextArea, because the incubator behavior registers its mouse handling as event FILTERS on its content pane — capture phase, no isConsumed checks. The first press moved the caret into the chip's paragraph, the virtualized flow rebuilt it and replaced the chip node mid-gesture, so the synthesized DRAG_DETECTED landed on the detached original and the drag never started; the drag events meanwhile text-selected around the badge. The second gesture found the caret already placed, nothing rebuilt, and the chip dragged. The tree renderer's press-consume precedent held only because those chips live in the block-stack document surface, not in a RichTextArea. KonceptChipGestures now claims the whole gesture from a capture filter on the RichTextArea control itself — the one place that runs before the content pane's filters. A press inside a KonceptBadge consumes press, drag, and release (no caret move, no rebuild, no selection), and at the drag threshold fires DRAG_DETECTED at the chip directly, inside the scene's live drag processing so startDragAndDrop is legal. Presses on text are untouched. Installed on all four chip-bearing areas: transcript, compose input, semantic lift, and document blocks. Fixes: #5 Refs: ikmdev/komet#742

The pattern row stretched the koncept atom to the full card — HGrow ALWAYS at the call site, MAX_VALUE max sizes on the badge, and an HBox filling its children's height — so the pill background painted the entire row instead of wrapping the sigil, identicon, and name at the chip's proportions. The badge now caps both max dimensions at its preferred size and sits centred on the left, so the white card supplies the margins and a navigator row presents a koncept exactly the way the inline chips do. Refs: #742

Hovering a chip inside a RichTextArea showed the text I-beam, misreading the badge as text. The hand now rides with drag-source identity on the atom itself: an identity-bearing badge sets Cursor.HAND — JavaFX resolves the cursor from the innermost node that sets one, so the chip wins over any host, the RichTextArea's I-beam included — and a presentation-only badge keeps the host's cursor rather than advertising an interaction it does not have. One rule on the atom covers every surface: transcript and compose chips, navigator rows, axiom trees. Refs: #742

…ergence The #861 status slice of the #742 amendment. KonceptStatus now delegates its vocabulary — glyphs, fork, colours, accessible names — to the single-sourced koncept-core KonceptStatus via core(), so the on-screen badge, the drag glyph, and every generated medium render the same marks by construction; komet.css notes it mirrors the enum. The badge installs the accessible reading as a tooltip on its status cluster and passes its live status to the drag glyph at gesture time. KonceptDragGlyph renders the one-leading-mark rule in full: a kind sigil for marked kinds, the copula cluster (≡/⊑/⊤ with the ⋎ fork) for a bare Koncept, with the nid+ViewCalculator overloads classifying via a new ViewCalculator-based KonceptBadge.computeStatus, so navigator and search drags carry status with no caller changes. Outset-frame refinement per the 2026-07-24 drag-rendering handoff (#885 interim): both bevel tones now derive from ONE base — the shared floating grey #c8d6e6 — giving a single retune dial; the pill's drag-affordance border reconciles from the subtle blue to the floating grey 1px per the #861 settled border policy; and the card is snapshotted at 2× and box-downsampled exactly 2:1, so integer edges stay pixel-crisp while text and the rounded pill corners gain supersampled smoothing. New KonceptDragGlyphSampleUTestFX writes variant sheets over the white and navigator-grey backdrops to target/drag-samples/ for frame-refinement judgment without launching the app. Refs: IKE-Network/ike-issues#861 Refs: #885

vollbrecht-work added 3 commits September 11, 2025 16:33

fix disable logic of properties in patternController

4da5a17

if the user creates a brand new Pattern ( not in database), than he can edit field_order otherwise the field is disabled if the user add a pattern than he is able to select a data_type otherwise the field is disabled

typo

3564a8c

dont allow to add field on already created pattern

a84532a

vollbrecht-work force-pushed the JPRO-203-te-feedback-allow-updates-of-each-pattern-field-purpose-and-meaning-of-a-published-pattern branch from ab67d9e to a84532a Compare September 11, 2025 15:19

carldea approved these changes Sep 11, 2025

View reviewed changes

Merge branch 'main' into JPRO-203-te-feedback-allow-updates-of-each-p…

16154e1

…attern-field-purpose-and-meaning-of-a-published-pattern

carldea reviewed Sep 11, 2025

View reviewed changes

Comment thread kview/src/main/java/dev/ikm/komet/kview/mvvm/view/pattern/PropertiesController.java

carldea approved these changes Sep 11, 2025

View reviewed changes

carldea added 2 commits September 11, 2025 14:53

Merge branch 'main' into JPRO-203-te-feedback-allow-updates-of-each-p…

4511737

…attern-field-purpose-and-meaning-of-a-published-pattern

Merge branch 'main' into JPRO-203-te-feedback-allow-updates-of-each-p…

62b8de6

…attern-field-purpose-and-meaning-of-a-published-pattern

carldea merged commit b0e93c0 into ikmdev:main Sep 15, 2025
3 checks passed

This was referenced Jul 24, 2026

Navigator and search cells drag a snapshot of the row instead of the standard Koncept badge #882

Open

KonceptDragGlyph renders no component-kind sigil — drag image and badge disagree #883

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

JPRO-203 fix disable logic of properties in patternController - #742

JPRO-203 fix disable logic of properties in patternController#742
carldea merged 6 commits into
ikmdev:mainfrom
vollbrecht-work:JPRO-203-te-feedback-allow-updates-of-each-pattern-field-purpose-and-meaning-of-a-published-pattern

vollbrecht-work commented Sep 10, 2025

Uh oh!

vollbrecht-work commented Sep 11, 2025 •

edited

Loading

Uh oh!

carldea left a comment

Uh oh!

carldea commented Sep 11, 2025

Uh oh!

Uh oh!

carldea left a comment

Uh oh!

carldea commented Sep 11, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

vollbrecht-work commented Sep 10, 2025

Uh oh!

vollbrecht-work commented Sep 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

carldea left a comment

Choose a reason for hiding this comment

Uh oh!

carldea commented Sep 11, 2025

Uh oh!

Uh oh!

carldea left a comment

Choose a reason for hiding this comment

Uh oh!

carldea commented Sep 11, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

vollbrecht-work commented Sep 11, 2025 •

edited

Loading