User feedback gathered from a live click-through review of the still-Hg-held Layer Groups
(#222/#782/#787/#789/#790) and JSON Note (#795/#796-801) feature branches, done while waiting
on the combined dev-ML review nudge posted 2026-09-17. All items reproduced live (Xvfb session +
the user's own separate desktop session, same build: Hg branch
layer-groups-json-notes-review-gtk3, rev 9aa297362f35).
== Layer Groups ==
Layers view has no way to see which group(s) a layer belongs to. The Manage Layer Groups
dialog only shows membership one direction (select a group, see its member layers) -- there is
no reverse lookup. Proposed fix: the Manage Layers dialog's third tab is literally titled
"Layers" but its only content is an empty "Layer links" field -- the pre-Layer-Groups mechanism
that Layer Groups was supposed to retire once migrated (see item A below). Repurpose that tab to
show which group(s) the currently-selected layer belongs to.
A layer can currently belong to multiple groups with no way to restrict it to one. This is
deliberate by original design (flat, independently-authored membership). User wants this kept as
a deferred idea for future consideration only -- not something to build now, and not an automatic
option.
3/4. "Show Only" (in Manage Layer Groups) has no inverse action. Once clicked, there is no way to
get back to showing every layer -- not from the dialog, not from Manage Layers, not by closing and
reopening either dialog. User got stuck unable to see all layers after clicking Show Only on one
group. Proposed fix: add a "Show All" button to the Manage Layer Groups dialog, visually separated
(e.g. a small gap/divider, maybe a light "Visibility" grouping) from New/Rename/Delete -- those are
group-management actions, Show Only/Show All are canvas-visibility actions, and lumping them into
one button column obscures that distinction.
A. (found live, not one of the original 4 items) The Manage Layers dialog's third "Layers" tab
still shows the dead "Layer links" field from the pre-Layer-Groups mechanism -- never cleaned up
after the migration that was supposed to retire it. See item 1's proposed fix, which repurposes
this same tab.
B. (found live) The View tab's "Object Count" field shows a garbage value ("H") instead of a
number. Not yet root-caused -- needs its own investigation, unrelated to the items above.
== JSON Note / Notes Report ==
Separately, and out of scope for this fix: user raised the idea of a tabbed Manage Notes dialog
exposing per-type visual properties (color/shape) so each note type could be styled differently.
Investigated: no data model support for this exists today (extraDataNote_t has no color/shape
field, the noteTypes[] table is toolbar-button metadata only). This would be new capability, not
a bug fix -- keep as a deferred idea, not scoped further here.
The Notes Report's Type and ROOT Names filter dropdowns require a manual "Refresh" click to
take effect. Confirmed live: switching the Type filter to "Text" left the "45 note(s) found" list
and count completely unchanged until Refresh was explicitly clicked. Proposed fix: wire the
dropdowns' selection-changed signal to also trigger the same refresh Refresh already performs.
Keep the Refresh button itself -- per the user's understanding, it exists to resync the list after
an interactive canvas edit (add/delete a note) while the report dialog stays open, and there's no
live-update hook for that case; this fix is only about making the filter dropdowns self-refresh,
not removing the button.
The Notes Report (both the on-screen table and Save/Print output) never includes a note's
actual JSON body -- confirmed by reading a saved report file directly. Only three fields are ever
populated per row: id, group (JSON notes only, via ROOT Names resolution), and label (extracted
from a "name" or "label" field when present). The parsed JSON is discarded immediately after those
fields are pulled and never stored on the row or printed. This isn't truncation, the JSON is just
never captured. Worth deciding whether Save/Print output should optionally include each note's
full raw JSON body.
For completeness, also confirmed (not a bug, just worth stating explicitly so it isn't "fixed"
later under a misunderstanding): "ROOT Names" filtering/grouping is JSON-note-only by design --
it scans a JSON note's parsed root-level keys and is meaningless for Text/Weblink/Document notes.
The code already has a comment saying so.
== Separately noted, not yet reproduced ==
User reported xtrkcad closing/appearing to crash when opening Manage -> Layer Groups after loading
a layout interactively via File -> Open. The same action worked cleanly when the same layout was
instead passed on the command line at launch. No coredump or crash log was captured for the
File->Open case yet -- needs a clean repro before it can be investigated further. Flagging here so
it isn't lost; may end up split into its own ticket once reproduced.
Anonymous
Follow-up on item B (Object Count showing a garbage value):
Reproduced live across ~11 different layers in the same layout -- Object Count shows a
different, seemingly-random character each time, not a fixed value. Every single occurrence is
paired 1:1 in the debug log with:
GetScaleInx: bad scaleInx -1 (scaleDesc_da.cnt: 48)
fired at the moment the View tab renders for that layer. This points at something passing an
invalid scale index (-1) into a scale lookup, with the failed lookup's return value then getting
formatted straight into the Object Count field as a raw character instead of being handled as an
error/default -- rather than a layer-specific bad-data issue. Worth starting an investigation
there (GetScaleInx call sites feeding the Object Count field on the View tab) rather than treating
this as isolated to one layer.
Follow-up on items 3/4 (Show Only has no inverse action) -- this raises their severity:
Confirmed live that the Show Only visibility state persists into the saved .xtc file, not just
the current session. Sequence: opened Manage Layer Groups, clicked Show Only on the Mainline
group, saved, quit, relaunched -- the file reopened still showing only Mainline's layers, exactly
as left. So this isn't a "stuck until you restart the app" annoyance, it's a state that gets
baked into the file itself. Anyone who opens that file later (including the same user, in a later
session) inherits the reduced visibility with no indication anything is hidden, and still has no
UI path back to full visibility short of manually re-enabling every other layer one at a time via
Manage Layers. Worth prioritizing the "Show All" button (item 3/4's proposed fix) accordingly --
this is closer to a data-affecting bug than a pure UI convenience gap.
All fixes implemented, merged into git GTK3V2MAIN (PR #213, squash-merged f6eb6a97, 26/26 CI green), and the Hg bug branch (bug-802-layergroups-jsonnote-review-fixes-gtk3) pushed to SF, both hops.
Summary of what landed:
Live-verified end to end, including a real save/quit/relaunch cycle confirming the Show Only visibility filter never gets written to the file.
Follow-up work planned under this same ticket: a real per-note-type properties system (configurable color/shape via new tabs in the Manage Notes dialog), replacing the fixed color mapping shipped here.
Follow-on to the Layer Groups/JSON Note review fixes above: implemented the Notes Properties
feature requested during live testing.
What's new: each of the four note types (Text, Weblink, Document, JSON) now has a
user-configurable color and marker shape (one of Square, Circle, Diamond, Triangle, Pentagon,
Hexagon, Octagon, Star, Cross, X), edited via new tabs on the Manage Notes dialog and persisted
as an app preference. Defaults match the color mapping already shipped above, so an unconfigured
install looks unchanged. The JSON tab also keeps the existing ROOT-Names registry
(Add.../Delete/Search) unchanged.
Verified: full CMocka suite green, internal-API Doxygen clean, live Xvfb testing of all four
tabs, and a live click-through on the reporter's own desktop confirming the dialog, color/shape
application, and canvas redraw all work as expected.
Merged into GTK3V2MAIN (git PR #214, squash f6eb6a97..5a2f32f1), Hg branch
bug-802-note-type-properties-gtk3 pushed to SourceForge.
Still to come under this same ticket: a refresh of the User Guide screenshots touched across the
whole Layer Groups/JSON Note arc (Manage Layers, Manage Layer Groups, Manage Notes, JSON Note
editor, Notes Report), several of which are stale or never had one.
Follow-up: User Guide screenshot refresh for the Layer Groups/JSON Note dialogs touched across
this ticket and the Notes Properties follow-on above.
Recaptured 6 stale screenshots (Manage Layers, Manage Layer Groups, Select Layers/Groups, and the
Print/Export and Notes Report layer filters -- the latter three turned out to still show old
Layer Group names, found during a spot-check) and added 3 new ones for dialogs that never had a
screenshot (Manage Notes' new tabbed layout, the JSON Note editor, the Notes Report). Also fixed
3 pre-existing Doxygen markdown warnings found while rebuilding the User Guide to verify the new
images resolved cleanly.
Merged into GTK3V2MAIN (git PR #215, squash 321097e7), Hg branch
bug-802-docs-screenshot-refresh-gtk3 pushed to SourceForge. This closes out all work planned under
this ticket.
Final follow-up: fixed Action Queue item 36 from the previous comment's screenshot refresh --
managem.dox's Layers Dialog page prose had drifted from a single-view GTK2-era description into
describing a dialog that no longer exists (the live Manage Layers dialog is a tabbed
View/Track/Layers layout, with several fields renamed: Frozen -> Lock, No Button -> Hide from
toolbar, Visible -> Canvas, On Map -> Map, Color -> Use Layer Color).
Rewrote the page into per-tab sections, verified every field name against the dialog's own GTK3
UI definition (not the older C source, which still has some stale internal label strings), and
newly documented the Track tab's Scale/Gauge/Min Track Radius/Max Track Grade/Tie fields, which
were visible in the old screenshot but had never been described in prose at all. Also swept the
rest of the doc tree and fixed 3 more stale cross-references to the same renamed fields
(cmdLayergroup's own prose, and two spots in the Display Menu page).
Merged into GTK3V2MAIN (git PR #216, squash 8ff5e7df), Hg branch
bug-802-cmdlayer-prose-rewrite-gtk3 pushed to SourceForge.
The "Show Only" button needs to be a toggle to essentially undo showing only the layers in the group. A "Show All" is handy but then shows other hidden layers that were hidden prior to showing only the layers in the group and not really doing the oppositie of the Show Only for the chosen layer group. I hope that's clear.