The plan is to eventually hide as much of the MacGui implementation as
possible from the rest of the engine, and only provide a minimal
macgui.h for it to use.
The GUI is now drawn on a sub-surface of the screen, and everything
inside it is positioned relative to that surface. This removes some of
the need to adjust things by _screenDrawOffset.
In an attempt to split up my previous commits, I accidentally applied
the position correction twice. Now it's only done once, and that means
that the banner window doesn't need a special case after all.
I do realize that it's a bit silly that we also adjust the coordinates
for 640x400 pixels earlier on, but if we want to keep support for that
resolution later that may not be a bad thing.
This matches what I see in emulation. Should this also be applied to the
Indy 3 dialog? The color version seems to draw a solid line, but the
black and white version is dotted. I don't have the time to look where
that is done at the moment.
Instead of hard-coding it. I still have my own conversion function, but
at least it's less error prone this way. I did it this way because I
couldn't find a readily available function for converting single
characters, only complete strings.
It's now the Mac dialog class that's responsible for saving/restoring
the screen shaking. (They were already responsible for pausing and
unpausing.) There are some other minor cleanups along the way, and the
drafts inventory can now be launched from the Apple menu.
Returning true means runDialog() returns so that the function that calls
it can act. Also, it's the "Open" button's responsibility to figure out
which save slot to use, not the list box. We may not have clicked on a
save slot yet. (I hope I understood this correctly.)
When dragging the handle, even if the calculated value doesn't change we
still need to reposition the handle, or it may be left sitting between
two values. This is particularly noticeable for the music quality
slider, which only has three possible values.
I didn't realize this existed. Once I found the one in base-str.cpp and
decided I couldn't use it, I wrote my own. But you should never get so
attached to any code you write that you can't bear to throw it away when
a better solution presents itself.
This prevents users from ever saving games with empty names, like
in the original and also removes my previous ugly hack for fetching
the savegame name string.
This means we won't have to set their color, and that clicking on them
automatically does nothing. (I hope I didn't accidentally disable
anything else in the process.)
Torbjörn Andersson
AndywinXp
D G Turner