If there are unicode characters in the link, it was leading to
wrong length calculation.
Example of such link:
![Menü-Symbol](menu.png \"Menü-Symbol\"){w=10em}
The problem is that for simplicity, we are working with UTF8 in
Markdown, but still with U32String in MacTextCanvas. This led to
the string length be calculated for UTF8, which is a multibyte
encoding. As a result, we were overshooting the link parsing
and reading texts as numbers.
This is kind of a hacky solution: we convert text to U32 before
caluclating the string length
When moving the mouse through the menu bar, over a part that's not
occupied by menu items, the Mac menu class will start calling
processEvent() recursively. This is bad for two reasons: During the
recursion (which can easily reach a depth of dozens or even hundreds of
calls) there is no delay, so it will use 100% CPU. And once the
recursion unwinds, all the delays will come at once.
This moves the call to eventLoop() to after the first event has been
fully processed. Hopefully that will have approximately the same desired
effect, without any of the bad side effects.
When GLAD fails to parse version, glGetError is null and raises a
SIGSEGV.
Current version of GLAD has a bug while parsing extensions so there is a
workaround here which should disappear when it's fixed.
Active MacWindows should always be passed EVENT_KEYDOWN events by MacWindowManager.
Previously it would only do so if the mouse was in the vicinity.
Fixes text input on the savegame screen of Team Xtreme: Operation
Weather Disaster.
It probably went unnoticed until now because the menu bar is
mostly used for black and white games, and in those instances
the green color is converted to black.
Tested with Indy3, Loom, The Apartment, Spaceship Warlock,
and several WAGE games.
Array::insert_at() is calling destructor for old data, whuch was freeing
the _table pointer that we are copying to new element which led to
use-after-free.
This moves MacTextLine cleanup to MacTextCanvas.
The menuTimerHandler() function is called from a timer, which means that
anything that it touches could potentially cause threading issues. I
suspect this is what's been causing the screen to go black for me a few
times, but it's not something I can reproduce at will. Add a mutex to
try and fix this.
By applying italics before outline, not after, and slanting italics
characters from the bottom up instead of top down, I now get pixel
perfect rendering for my experimental About dialogs for Loom and Indiana
Jones and the Last Crusade.
This is already done in keyEvent(), which is the only place where
processMenuShortCut() is called. This allows using Alt-<key> as
shortcut, which is consistent with how the Mac emulators I've tried does
it.
