Improve how menus are displayed with invisible > indicators

[curiousdannii]

TADS menus print a > at the beginning of each line, rather than a space.
It is not visible however because the colours are set to modes that are meant to make it transparent.
Without measuring colours (as it is not yet possible with Remglk/GlkOte) we can instead replace the invisible text with spaces.
But this is not perfect as the width of one proportional width > and one fix-width space may not be the same.

[curiousdannii]

Maybe it would be better to do this only if measuring doesn't work? But is it worth that complexity, just for 1-2 pixels of misaligned text?

[angstsmurf]

Maybe it would be better to do this only if measuring doesn't work? But is it worth that complexity, just for 1-2 pixels of misaligned text?

I'd say it's worth a bit of extra complexity to make the text line up nicely.

[curiousdannii]

Okay. I'll probably rework this to be based off your earlier method, and then use the replacing-with-spaces only if measuring doesn't work.

[curiousdannii]

@angstsmurf I switched to your patch, and then built my method on top.

Though this probably really needs to have the rest of the colour changes applied too.

Edit: this PR now includes #4 as well

[curiousdannii]

@angstsmurf Did you have the chance to test this?

[angstsmurf]

I tried it out in Gargoyle (on macOS ARM) on Thaumistry: In Charm's Way and The Devil in the Details, and it looks and work great. Much nicer than the old Gargoyle way to display the TADS 3 menus.

Let me know if there is anything in particular you want me to try. I have not been able to test this with Spatterlight yet.

[cspiegel]

I've tested this against Gargoyle as well. I use white on grey for my default Gargoyle colors, and that seems to cause some misbehavior with this patch.

Here's how things look with the current master of this repository playing Dark Angel:

When I apply the changes in this pull request:

I just tested with a white background and it's also not ideal:

Original:

Patched:

For reference, here's what QTads looks like with the same color scheme as Gargoyle's white on grey:

[curiousdannii]

Well the main thing this PR is meant to do is fix the multiple >s being shown in menus, and it seems like that is working. We have more work to do to improve the general styling and colour support.

But considering many games have weird looking styles even in qtads I'm not sure how much we can do.

In addition to fixing the > problem, this PR also switches to real reverse stylehints for reverse mode, and also temporarily disables os_banner_set_screen_color. I assume its that last thing that is causing issues.

I think I'll merge this now, cause I expect to have time to work on the other colour functions later today. So hopefully they'll be much improved too!

[curiousdannii]

@cspiegel Actually, thinking again, I realised it was a mistake to put the third commit into this PR. I wanted it for Parchment, and was lazy and included it here, when I should've made a separate branch for Parchment to reference. Sorry for that.

I'll take out the last commit. The other two should be a strict improvement over what Gargoyle currently has.

[realnc]

Dark Angel forces a white background for some of the text it prints. So these screenshots are all correct, actually. This is a bug in the game. It looks like that even with htmltads.exe from the Windows TADS Player Kit.

What the game should be doing is use parameterized background colors (like bgcolor or statusbgcolor), which are intended to match the current background color, whatever it happens to be. But instead, it uses white. So these results are expected and correct.

[cspiegel]

Dark Angel forces a white background for some of the text it prints. So these screenshots are all correct, actually. This is a bug in the game. It looks like that even with htmltads.exe from the Windows TADS Player Kit.

The issue I have is that the patches vs unpatched versions differ. The white background in the text does look wrong, but shouldn't it be wrong consistently? Dannii notes that there are upcoming color fixes so it may be moot, but I can't see how all screenshots can be correct when some contradict each other.

In short, the status bar is "properly" reverse video in the unpatched version, but not reverse in the patched. The forced-white background is a red herring here, as it's the general look of the status window that looks wrong.

I'm assuming the reverse-video status bar is right, given that QTads does it.

[realnc]

I'm assuming the reverse-video status bar is right, given that QTads does it.

These are supposed to be user preferences. The standard Tads game library (adv/adv3) doesn't actually try to force any kind of color for banners. The interpreter is free to choose whatever color it wants, both for banners as well as the main window. QTads just uses the same text color for banners and the main window, and a gray background for banners. Even though this isn't a completely arbitrary choice (it just copied what htmltads.exe does), it's perfectly legal for a terp to choose different default colors and allow users to change them.

If a game wants its status bar (or any other banner window it creates) to have a specific background color, it must do so explicitly.

[curiousdannii]

@cspiegel The changes to window styles were an extra commit that is no longer part of this PR, and wasn't merged into master. I'll keep developing the style changes and present a PR that is a full upgrade.

We do definitely need some style changes though, as #3 is a major bug. In #7 I proposed that all colour support in TADS moving forward switch to using the garglk extension functions.