You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fields: let RmlUi own the drag; Objects: let the user leave Add mode
The drag was hand-rolled on the engine's mouse callbacks, and it could not
work: the engine hands mouse input to its RmlUi contexts *before* its event
clients, so a press on the panel never reaches the plugin at all. We never
become the engine's mouse owner, and no mouse_release is ever delivered for a
field -- which is why a drag released outside the panel stayed latched to the
mouse no matter how many times it was "fixed" (logging the callbacks showed the
panel presses simply never arrive).
RmlUi has drag support with pointer capture: `dragstart`/`dragend` arrive
wherever the button comes up, on or off the element. The field opts in with
`drag: drag` and is bracketed by those events. mousedown/mouseup now only decide
whether a press was a *click* (which opens the inline editor).
That deletes the guesswork: no drag threshold of our own, no force_drag_release,
no reading the button state the engine does not have.
Objects:
- The Add/Brush buttons toggle, as Lua's action buttons do. There was no way out
of Add mode: every click on the map kept placing, so a placed feature could
never be selected or dragged.
- A field change only re-arms placement if the value actually moved. RmlUi fires
`change` for the values the editor writes back, and re-arming on those threw
the user out of what they were doing -- a refresh mid-drag re-entered placement
and previewed ghosts over the object being moved.
Verified: a drag released out over the map commits and stops (asserted: nothing
more is sent afterwards); toggling Add off makes the next map click select the
feature rather than place a second one (one AddObjectCommand, not two).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
0 commit comments