test: the locked signal list keeps its drag, and the reading says so
Asked for: dragging a signal onto a plot must still work in the compact (view) list. It does — the drag
source is on the *row* and was never conditional on the lock — but nothing said so, and "the lock rebuilds
this list and drops three of its controls" is exactly the change that could take the drag with it. Now it
is a reading: **`drag_sources` must be `rows - 1`**, one per signal row, the `MATH` divider not being
draggable.
signals panel: … rows=3 signals=2 math=0 divider=1 drag_sources=2 (locked)
signals panel: … rows=5 signals=4 math=0 divider=1 drag_sources=4 (configuration mode)
Measured the direct way first, with a throwaway walk of the list's rows and
`gtk_widget_observe_controllers()`: `locked=1 rows=3 rows_with_a_drag_source=2`, the third row being the
divider. That is where the number in the reading comes from, and the walk is what found the shape of the
answer rather than assuming it.
One consequence worth recording, because it is an improvement rather than a cost: a locked row can be
dragged from *anywhere* on it, the colour chip included. In configuration mode the chip carries a click
gesture that claims the event sequence precisely so a drag cannot start there (it opens the colour
chooser); the locked list does not build that gesture, so the chip is inert and the row's drag source
sees the press.
What the lock does *not* change is which signals are listed: only the ones that are on. A signal nobody
acquires draws nothing on a plot, so a row for it would be a drag that ends in an empty slot.
Verified: both lines above, from sessions differing only in whether one exists; `make test-ui` 14 files;
zero `Gtk-CRITICAL`. Docs: the `drag_sources` field with what a `0` would mean, the invariants' lock
bullet, and the README's note.
This commit is contained in:
1 parent
d8705a369f
commit
a43d3830f0
6 files changed
+36
-5
No files matched your search
@@ -2403,7 +2403,9 @@ now — they are listed so they are not mistaken for anything else:
|
||||
accessible name. Both panes also have a **locked** mode, which is what a returning user gets: the
|
||||
trigger pane shows one line saying what it is set to, the signal list shows only the signals that are
|
||||
on, and neither offers a control that changes the configuration — each heading has an `[edit]` button
|
||||
to switch to the full pane, and back. A **first run** (no session file for that source) comes up
|
||||
to switch to the full pane, and back. Dragging a signal onto a plot still works while locked — filling
|
||||
plots is what the list is for, not configuration — and a locked row can be dragged from anywhere on it,
|
||||
the colour chip included. A **first run** (no session file for that source) comes up
|
||||
unlocked, because configuring the host is what a first run is for. Each pane's heading also carries its **own switch**, the same control as the
|
||||
header bar's button — clicking either moves both — because a pane that is *disabled* while its
|
||||
feature is off is a pane whose controls you would otherwise have to leave to turn it back on. The
|
||||
|
||||
Reference in new issue
Block a user