85ad194d introduced a patched winit.
In the glium build, we were pulling in a second version of winit (the
unpatched version, via glutin). This caused conflicts between the data
types, breaking the build.
Apparently the proper way to specify a patch like this, usable by
transitive dependencies, is via cargo's "patch" specifiers
combining primitive transitions into sequences.
Brief context on the state/transition system: The game crate is
organized as a stack of states, with the topmost one being active.
Transitions manipulate this stack. For example, the stack might look
like: [main menu, sandbox mode, edit mode, traffic signal editor, signal
picker]
watching https://www.openstreetmap.org/node/53214134 on the weekday
scenario. At some point, an arrow polygon with an inner ring is scaled
down, collapsing its points so much that the ring becomes invalid.
These are my best guess at the changes to get glow working with the DPI changes.
Currently on master, on macos at least, building the glow backend
launches a blank screen. That's not resolved by this PR, so all these
changes are untested.
Previously it was not clear (to me at least) when a value used
in layout was in units of logical pixels vs physical pixels.
This lead to some ambiguity about where to scale values, and lead to
some values being scaled more than once or sometimes not at all, leading
to inconsistent layouts across DPI's.
The intent of this change is to solve this ambiguity by having the ui
clients work *exlusively* with logical pixels.
To achieve this, we consolidate all scaling to the graphics backend.
We translate all PhysicalPositions from the windowing libraries to
LogicalPixles.
Our own types: ScreenPt, ScreenDim, etc. are all in logical units.
In some places, I replaced passing raw floats with a corresponding
Screen* type to clarify that the units are in logical pixels.
- stop referencing Prerender when easy
- default_font_size hasn't been used since the great typography refactor
some of this harms the usability of map_editor, but that's fine, because
the UX is awful anyway, and nobody should be using this except for me
very occasionally. long-term fate of it is to go away.
* revert some switches back to checkboxes
partial revert of 90bb4ac0
In many ways switches and checkboxes seem interchangeable, but in certain
contexts one may be more appropriate.
For an overview that I mostly agree with:
https://uxplanet.org/checkbox-vs-toggle-switch-7fc6e83f10b8
