Menu improvements

[curiousdannii]

A few people have said they'd prefer a numerical menu. Let's do it.

Should we keep the arrow at the same time? Maybe.

We could also add hyperlinks!

[ektemple]

Sounds good to me, I've never liked the standard arrow-based menus.

One problem: if any page has more than 9 items, numbers won't work, which means that some kind of hybrid system will be necessary.

[VictorGijsbers]

What would that look like? I'm not entirely sure I'm in favour of it if it looks like a conversation menu. That is a nice format for something happening in the game, but seems like an ugly format for a help menu.

[curiousdannii]

The guys at audiogames said the menu was especially bad for screen readers, but all Inform menus would be like this.

What I'd imagine would be having a number at the side, rather than the >. I don't image it would be any uglier than what it is currently, which isn't very attractive anyway! It would still use key input rather than line input like a convo menu normally does.

I think though that if hyperlinks work that might be a much better approach. Or we could have both.

[ektemple]

It might be worth testing, maybe with the help of the audiogames folks, whether hyperlinks in Gargoyle work well with standard screen-readers. If so, then that probably is the ideal method for accessibility.

I'm sure that there are IF aficionados, though, that would also appreciate a mouse-free way of navigating the hyperlinked menu.

[curiousdannii]

Oh, if I added hyperlinks I wouldn't remove keyboard navigation! It might not work to have both arrow and numerical navigation, but we might be able to switch between them.

I was under the impression that Gargoyle doesn't work with screen readers at all.

[ektemple]

It would be easy to believe that Gargoyle doesn't support screenreaders given that it's libraries are nonnative. That's why I suggested the test. But if Gargoyle doesn't work well with the screenreaders, then we should be careful making it the recommended interpreter...

As I said above, I don't think you'll be able to do numeric navigation in some menus, or at least you may have to redesign the menu to require more paging so that no menu ever has more than 9 or 10 links.

[VictorGijsbers]

Using letters instead of numbers would increase the limit to 26. (I believe DCSS does that in its help menu. In fact, it also does in its inventory menu, where it is case sensitive. Guess why DCSS has an item limit of 52. :) )

[VictorGijsbers]

(By the way, Erik, where are you, geographically?)

[ektemple]

Yes, and I guess there is a long tradition of using arbitrary letters as commands in roguelikes anyway!

I am a northerner transplanted to the southeastern US.

[VictorGijsbers]

Dannii, I've assigned this to you because I believe you were working on it. Feel free to unassign yourself if that isn't the case.

[curiousdannii]

Things I'm planning:

• Proportional text in status line
• Proportional text in menus
• Hyperlinks in menus

It doesn't seem possible to change the colour of hyperlinks from game code, so I'll include an .ini file for Gargoyle.

[ektemple]

Good, I've been wanting to do an .ini file anyway. I think we should eliminate the overall window margin and instead use margins within windows. That's actually my standard .ini setup--0 margins around the main window, and a 7px margin within each text window.

Guess we'll need to add the Release folder to tracking (makes the most sense to put the .ini file there), along with some more .gitignore rules for the gblorb and datafiles.

[curiousdannii]

Section 23.6 says such files should go in Materials, so we can keep ignoring Release. :)

[ektemple]

Maybe, but Gargoyle won't see them there when we are running the test gblorb out of the Release folder. Unless we include a "release along with the file garglk.ini" in story.ni, which is of course just what we should do!

[ektemple]

By the way, using proportional text in the status line will be difficult to get right and take a lot of code rejiggering, because you won't be able to use the status window for proportional text. Don't won't to try to dissuade you if it's something you feel strongly about, but it will require a fairly complete rewrite of the Menus extension...

[curiousdannii]

Would each text window have a 7px margin? That won't work with my changes to the status line... we'll have to try both out and see which is more valuable. And the margins could always be faked with graphics windows.

[ektemple]

Only text-buffer windows get the margin. Text-grid windows (i.e., the status window) and graphics windows don't get it. If using inner margins ruins something, we don't have to do it.

[curiousdannii]

I've discovered that Gargoyle doesn't support changing the text justification or text size, so that sucks! I'll put my extension in the i7/extensions repository, but I'm abandoning it for now. :(

[VictorGijsbers]

Maybe you can contact the Gargoyle maintainers?

[curiousdannii]

Yep I've reported it as a bug already.

I'll still try to get the hyperlinks working, but another day when I feel more enthused :P

[ektemple]

It would be nice if the menu's selector rolled over, i.e. when you scroll to the bottom and then press the down arrow key, the pointer jumps to the first item (and vice-versa).

By the way, Dannii, it's definitely an also-ran solution, but we can customize the color of hyperlinks in the .ini file.

[curiousdannii]

Hmm, that would be good indeed, but would be a substantial change. Might as well add it to the list though.

And yeah I have tried that. It works, but it's Gargoyle specific of course. I couldn't see any corresponding option for WinGit.

[curiousdannii]

I've moved this to i7/extensions#1.

[ektemple]

WinGit will almost certainly offer a sub-par experience for graphics, so we'll probably want to just drop support for any terp but Gargoyle anyway.

[erkyrath]

Can the problems with WinGit (WinGlk) be characterized well enough to be fixed? Targetting one interpreter is not the ideal outcome.

[ektemple]

Targeting a single interpreter does make sense when it's the best looking
and best performing, and can give essentially the same user experience on
all platforms. The main issue with Gargoyle is that it doesn't work with
screenreaders, so it needs to work on other terps with the graphics turned
off (as indeed it currently does).

Re WinGlk, I think David worked out the graphics bugs and also a few
display issues a couple years back. The main remaining issue is simply that
the display library used by WinGlk is slower than Garglk's. It's possible
that this only makes a difference on older machines or via emulation (the
latter is how I usually have to test it), I'm not sure.

Zoom has similar issues, though on a newer machine than mine (5-6 years
old), it might not matter so much either. (There is a long-standing and
many-times-reported bug that reports the size of text windows in pixels
rather than characters, which would probably break the fancy status line
Dannii has been planning.)

On Sun, Feb 10, 2013 at 10:09 PM, Andrew Plotkin
[email protected]:

Can the problems with WinGit (WinGlk) be characterized well enough to be
fixed? Targetting one interpreter is not the ideal outcome.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-13367857..

[erkyrath]

I know that Zoom has bugs; I hope they are addressed someday, but there hasn't been an update for a while.

If WinGlk is compatible except for speed issues, that's good enough for me. I hope people will keep an eye on it testing-wise, so that if any new display issues turn up, they can be dealt with rather than allowed to fester.

[ektemple]

Yeah, the frustrating thing about that Zoom bug I mentioned is that I reported it well before the last update, and it wasn't fixed. It's a pretty serious bug, because there is no workaround.

Both CocoaGlk and WinGlk seem to do fine with graphics and timer functioning--they're just slow, and so provide a sub-par experience vis-a-vis a game with intensive graphics.

[curiousdannii]

The menu should accept more keys than space to go back to a menu from a text page. All keys except page up/down probably (because gargoyle sends mouse scrolls as page up/down.)

Also, we could consider using Wade's menu extensions. They would let us use alphabetical menus. :)

[ektemple]

Just for the record, I used the standard Flexible Windows hyperlinks treatment for the Statistics and Powers windows. Hyperlink numbers are filtered by window in my implementation, so numeric IDs can be repeated as long as the links within each window are unique. A bit more info:

Statistics window

• Link 1 corresponds to clicking on the "show full report" link.
• Link 2 corresponds to clicking on "back".

Powers window

• Link numbers for each power are assigned by the object number of the power (typecasting the object to a number). In practice these are usually five-digit numbers.
• Link 2 corresponds to clicking on "back".

[mciul]

Can this be closed now?

[curiousdannii]

Not yet. Soon I hope!

[curiousdannii]

In Gargoyle text is aligned to the bottom of each window. One possibility I have considered is to vertically align the text to the top of the menu using an extra window. Do you think it's worth doing that? We couldn't do it with the rest of the windows, so it would only help with the menu (and even then only in the actual menus, not their content pages.)