The goal was to let finger flicks that didn't qualify as panning commands cancel momentum scrolling. The final effect is that any click does, which is fine.
Save title can now overlap with the vote buttons again. It doesn't look great, but reorganizing the preview view is a task for a later day. Save titles this long are rare.
Namely, gravity zones would be rendered when the wrong wall (i.e. not Gravity wall) was selected if custom tools were present in the SC_WALL menu section. This was because their rendering was tied to a tool index into the SC_WALL menu section, rather than to a tool identifier.
Namely, when no completion callback is specified, they use themselves, of all things, as their completion callback, because lua_gettop returns 0 and somehow Lua is ok with that stack index and thinks it refers to the function being executed.
SaveButton relies on the SaveFile/SaveInfo passed to it at construction being alive until its destruction, or at least while it's being ticked (while its Tick is being called). While SaveButtons are owned by views, SaveFiles/SaveInfos associated with them are owned by models, so models need to immediately notify views (their observers) of changes made to SaveFiles/SaveInfos, or otherwise prevent views (and thus SaveButtons) from accessing stale SaveFile/SaveInfo pointers.
The online save browser model (SearchModel) correctly notifies its observer (SearchView) about changes to its list of SaveInfos. The local save browser (FileBrowserActivity) is not MVC and simply either fully exits when its SaveFile list changes, or it cleans up its SaveButtons beforehand. The stamp browser model (LocalBrowerModel), however, would make changes to its SaveFile list without notifying its observer (LocalBrowserView) when selecting a stamp, so the latter might tick its SaveButtons after SaveFiles associated with them had already been cleaned up. This commit adds the missing notification.
The crash would manifest when the SaveFile associated with a stamp was accessed for the GameSave it owned to be sent off for rendering with ThumbnailRendererTask.
Which optionally enables loading Lua shared modules from within even static TPT. Not that anyone actually needs this.
This currently can't work on Windows because DLLs there import symbols by [module name, symbol name] rather than just symbol name. One could in theory export Lua symbols from TPT (I don't know the exact MSVC hack this would require, .def files?) and place a lua51.dll next to the executable that just re-exports them, see https://learn.microsoft.com/en-us/cpp/build/reference/exports?view=msvc-170 , but I've yet to try this.
Profile Viewer: a few "Not Provided" labels were cutoff. The score labels overlapped with the scrollbar and prevented clicking on it.
Save Preview: Views label cutoff on saves with over 10M views (aka only id:2198). authorDate label cutoff on saves with really long usernames. This one I "fixed" by making it overlap again like it used to. It only affects a few 2nd and 3rd page saves.
Options UI: Fix ambient air temp label overlapping with textbox. Fix all checkbox secondary desc labels overlapping with checkbox itself. I "fixed" this by adding the checkbox after the label so that clicks take priority, rather than actually fixing the overlap.
Very similar to ab28f93753. Broken by 69e0a8b0aa where I added an extra MouseDownInside check to the OnMouseDown (used to be OnMouseClick) of every component except that of sliders AND apparently panels, great.
Rather than to the front. It's nice to immediately see stamps that you haven't seen in years but it's even nicer if your most recently used stamps stay easily accessible.
desktopWidth/desktopHeight were initialized only at the end of SDLOpen, after we checked if larger scales were supported. Need to initialize the window first, then recreate the window after if the scale can be larger. The window won't be centered, but otherwise it works.
Save Name is limited to 50 characters by the db column, so stop it there
Ambient Air Temp glitches out when it's too long, so limit to 9
Limit profile location to 40 to prevent spam / abuse
Limit tags to 16 because that's the max the server accepts
Namely, everywhere except in the network part (first line) of the intro text, since that should be customized more extensively by a client+server developer.
Visible since c3cd4f1691, which made element search scrollable.
They would behave as if the scroll panel was never actually scrolled, i.e. tooltips might be shown that belonged to buttons far outside the visible part of the panel's inner area. This was because Panel invoked the OnMouseHover of its children wrong, without taking scrolling into account.
Broken by 69e0a8b0aa where I added an extra MouseDownInside check to the OnMouseDown (used to be OnMouseClick) of every component except that of sliders.
But this is very buggy, ToolButtons don't lose their hover state when they get scrolled out from under the cursor and the scroll bar ignores clicks if they land on a component under it.
This is a prerequisite for making ScrollPanel work nicely on touch screens.
Engine used the terms MouseClick and MouseUnclick to refer to events that are traditionally called MouseDown and MouseUp, this was fixed with simple renaming.
Component and friends similarly used the terms MouseClick and MouseUnclick to refer to events that are traditionally called MouseDown and MouseUp and, succumbing to their own confusing terminology, also implemented behaviours associated with both the actual events MouseDown and MouseClick in code that was responsible for handling only the actual event MouseDown (i.e. what they called MouseClick).
This had been overlooked for a long time because nobody cares that a checkbox changes state when the mouse button is pressed on it rather than when it is released.
The fix is to migrate many pieces of code that run in response to MouseDown events, such as checkbox state change code, to MouseClick events, and to redefine a MouseClick to mean a sequence of MouseDown and MouseUp inside the component, rather than just a MouseDown. This is complicated by the fact that MouseClick events report mouse coordinates relative to the top left corner of the component, while MouseDown events report them relative to the top left corner of the container of the component.
Other pieces of code that make sense to be run in response to MouseDown events, such as label selection code, were left alone.
