Terraform MMB Behaviour

[Birdulon]

Currently, terraforming has rather unusual behaviour surrounding middle mouse button, which I tend to use for panning while doing other commands. Not sure how much is engine vs widget. Ramp is currently in the best state.
EDIT: Looking at gui_lasso_terraform again I think it probably won't come down to engine.

Expected Behaviour

Normal panning controls. Just like Move/AttackMove/Patrol/ForceFire/Guard/AreaMex/Repair/Reclaim/SetTarget pre-click phase (things get weird while you're LMB click-dragging those, but that should probably be another issue).

Observed Behaviour

Before Drawing

Ramp

Normal panning controls. Very convenient.

Level, Raise/Lower, Restore, and Smooth

Immediately cancels out of the command, as if RMB were pressed. Very frustrating.

While Drawing

Ramp

One click: Normal panning controls!
Drag click: While LMB held, seemingly nothing - but when you release LMB after having pressed MMB, it acts almost like you're in One click mode, but it doesn't allow changing the elevation at the "second" LMB click, and you can do various things to get it more broken from this state.

Level, Raise/Lower, Restore, and Smooth

On MMB press, it goes into straight line mode, similar to holding Ctrl. It doesn't stop when you release MMB. It doesn't stop when you release LMB. Whenever you (press and) release Ctrl in this state, it starts a new line segment. LMB must be released and pressed again to proceed to the elevation step for Level or Raise/Lower, or to execute the command for Restore or Smooth.

Final Step

Ramp

Normal panning controls while setting width, though the width control fights the cursor movement in a janky way.

Level, Raise/Lower

Normal panning controls while setting elevation, though the elevation control fights the cursor movement in a way that makes either task very janky.

[Birdulon]

Some more testing:
Adding if button == 2 then return end to the start of widget:MousePress and widget:MouseRelease prevents the cursor cancelling out on the Before Drawing step. Good start, but doesn't solve the steps that rely on captured mouse input. I experimented with naively trying to retain the mouse input with return drawingLasso or setHeight or drawingRamp or simpleDrawingRamp or drawingRectangle or placingRectangle and even return true but it didn't seem to actually do so. I'll have to play around more.

[GoogleFrog]

Figure out which mouse button the MMB is and stop it from reaching the cancel terraform branches.

[Birdulon]

This block here is responsible for any mouse button other than LMB (==1) cancelling out of the pre-draw stage of Level/RaiseLower/Restore/Smooth:

Zero-K/LuaUI/Widgets/gui_lasso_terraform.lua

Lines 1187 to 1191 in 6a5ec29

	else
	spSetActiveCommand(nil)
	originalCommandGiven = false
	return true
	end

I noticed no ill effects from changing the else line to elseif button ~= 2 then (MMB == 2 in SDL), however this still cancels with Mouse4 and Mouse5, which is not how Ramp or any normal command works. I could PR a single line elseif button == 3 then to make it RMB cancel only for consistency, however I think there's a case for refactoring.
There's another RMB check further down:

Zero-K/LuaUI/Widgets/gui_lasso_terraform.lua

Lines 1236 to 1241 in 6a5ec29

	if drawingLasso or setHeight or drawingRamp or simpleDrawingRamp or drawingRectangle or placingRectangle then
	if button == 3 then
	completelyStopCommand()
	return true
	end
	end

Removing both of the above blocks and just putting a if button == 3 then completelyStopCommand(); return end at the top of widget:MousePress would make it more clear that RMB always cancels, regardless of state. On that note, an early exit for button ~= 1 seems appropriate too, it currently performs every top-level check in the widget for any mouse click (i.e. even without any terraform command selected), even though it does nothing for anything other than LMB.

As for all the other behavioural oddities:
My current understanding is that the callins widget:MouseMove and widget:MouseRelease aren't going to achieve what I want, as they don't gracefully handle concurrent mouse button presses¹. MMB panning with LMB released is possible for parts of the command that don't involve holding LMB (e.g. one click ramp mode, the height step of Level/RaiseLower) but being able to MMB scroll while holding LMB to drag a lasso/line would require monitoring the mouse position changes and LMB release with Spring.GetMouseState in widget:Update and dropping MouseMove and MouseRelease entirely, just using MousePress to tell the widget to start polling mouse state.

Footnotes

1. widget:MouseMove and widget:MouseRelease require the widget to return true from a widget:MousePress callin (boolean becomeMouseOwner). Returning true from a MMB press blocks MMB scroll entirely. Returning false does nothing useful, and once MMB is released, widget:MouseRelease fires for MMB, after which no more move or release callins will fire even when LMB is released, until another MousePress becomes the mouse owner again. So relying on this API simply can't work for concurrent mouse button events. ↩