DrRacket's interactions window tried to treat numpad Enter the same
as ctl-Return: send input to the reader, even if an S-expression is
incomplete. Since numpad Enter events were not reported as
'numpad-enter, however, the special treatment didn't take effect.
Meanwhile, it appears that some keyboard configurations report a
numpad Enter event when NumLock is on and the regular Enter key
is pressed, and that's probably not what a user wants. And
numpad Enter has never been reported differently from regular
Enter on Windows.
So, it's simpler and more consistent to just treat numpad Enter
and regular Enter the same.
On Unix and Mac OS X, the key has long been reported as #\u3,
even though the documentation says 'numpad-enter.
A more compatible change would be to adjust the documentation and
also change DrRacket and the framework to recognize #\u3 instead
of 'numpad-enter. But there doesn't seem to be a good reason to
treat #\u3 as "numpad Enter" --- particularly as opposed to treating
it as "Ctl-C" --- other than ancient Mac history.
On Windows, numpad Enter continues to be reported as #\return,
since Windows event handling doesn't naturally or easily distinguish
the two keys.
On Windows, a "soft link" or "junction" is different from a
"symbolic link". The current Windows documentation is
incomplete in that it describes the behavior of GetFileAttributesEx
for a symbolic link, but not for a junction, and I guessed wrong.
For consistency, junctions need to be treated like symbolic links.
The specialization to Win64 to work around a Cairo clipping
problem probably had more to do with the version of Cairo,
instead of the variant of Windows, since both variants need the
workarounds after a Cairo upgrade.
A pan gesture is turned into a WM_{H.V}SCROLL event in a
way that `racket/gui` did not recognize as a change to the
scrollbar. I'm not sure that this change fixes the problem,
but it seems worth a try.
For a font with 'aligned hinting, the font map caches metric
information that depends on the destination transformation,
at least on Windows. Make the font-map cache sensitive to the
destination's current transformation.
This bug was exposed by support for DPI-aware GUIs on Windows,
but the problem was more general.
Roundoff can place a child of a container so that it's position plus
width extend beyond the container's width. For some controls, that
looks especially bad. Approximate precise scaling by having those
control sizes round down, instead of up, while leaving other kinds
of controls alone.
The `racket/draw` library is now independent of the screen resolution
on Windows. Font sizes in "points" are the only place where the
resolution mattered before, and now `racket/draw` assumes a
traditional 96dpi on Windows and Linux (and a traditional 72dpi
on Mac OS X).
Setting the scale for "text and other items" in Windows now adjusts
the backing scale of screen and canvas-compatible bitmaps, as well as
setting a scale on canvas drawing. Window and screen positions and
sizes are similarly scaled; for example, if the screen is 2048x1436
with text scaled by 200%, then `racket/gui` reports the display size
as 1024x768 (and the display backing scale as 2.0).
Backing scales of 1.25 and 1.5 are common for Windows. Rounding
associated with those scales could cause trouble for virtual -> actual
-> virtual conversions.
by making the equal, eq, and regexp contracts all have
an extra field to hold the name. This mostly has the advantage
that flat-named-contract has to turn a flat contract into it's
predicate a bit less often
