Issues with new menus

[ektemple]

I only have one issue to report at this point, but I thought I'd make the title general enough to do double-duty in case we find more.

If you get to the credits menu section by typing CREDITS rather than going through the menu system, it returns you to the game with a blank screen and a prompt. It should trigger a silent LOOK command as returning from a menu does. There may be other direct commands that cause the same issue, or this may be the only one.

[curiousdannii]

I'm sure there would be some problems, so good catch!

I'm hoping to use your idea of having the map pop over the main window, so that we won't need to clear the main window.

[curiousdannii]

I've done that and it seems to be working well.

But when you go to the menu from the (text) title screen the status window isn't shown. I tried a few things to open it, but I couldn't get it to work. Could you take a look Erik?

[curiousdannii]

The "report the main action again" stuff can be removed from ATTACK now too... (A note for myself. It's time for bed!)

[ektemple]

I don't have the same issue with the status window disappearing. It comes back for me after dismissing the menu. (I am testing without the graphics extensions compiled in, BTW.)

The main window is still be cleared, despite the popover window. Now after clearing it says:

Ok.

>

The screen-clearing happens whether you've gone into the window proper, or whether you've made a shortcut by typing CREDITS. CREDITS displays inline in the main window, while other menu commands take you into the menu interface. (CREDITS nevertheless clears the main window in the same way on return.)

[curiousdannii]

Hmm, I was only testing with the text menu. I'll take a look at it with graphics.

[ektemple]

I tried it with graphics last night, works fine there as well.

However, I tried updating Flexible Windows and Menus just now, and I'm getting compilation errors. So I suspect that some things are updated on your end that I don't have symlinked up here. At a quick glance, the errors seem like they may imply misordering of extension inclusions.

Here are the errors I get with graphics:

In Chapter 5 - Writing to different windows, Section - Background colours in the extension Flexible Windows by Jon Ingold:

Problem. You wrote 'Table of Common Color Values (continued) glulx color value assigned number g-placenullcol 0 g-darkgreen 25600 g-green 32768 g-lime 65280 g-midnightblue 1644912 g-steelblue 4620980 g-terracotta 11674146 g-navy 128 g-mediumblue 205 g-blue 255 g-indigo 4915330 g-cornflowerblue 6591981 g-mediumslateblue 8087790 g-maroon 8388608 g-red 16711680 g-deeppink 16716947 g-brown 9127187 g-darkviolet 9699539 g-khaki 12433259 g-silver 12632256 g-crimson 14423100 g-orangered 16729344 g-gold 16766720 g-darkorange 16747520 g-lavender 16773365 g-yellow 16776960 g-pink 16761035'  : but this does not seem to be a continuation or amendment, since the name/number do not match any previously defined table. (Perhaps you've put the continuation or amendment before the original?)
In Section - Glulx color value KOV in the extension Glulx Text Effects by Emily Short:
Problem. The table name 'Common Color Values'   will have to be disallowed as it is already the name of an existing table (of which it is not a continuation).
In Chapter - The map window in the extension Kerkerkruip Glimmr Additions by Erik Temple:
Problem. The table Common Color Values was said to be a continuation or amendment, but it contains columns not found in the original.

Here are the errors I get without graphics:

In Book - Glulx interface tricks (for Glulx only), Part - Glulx Menu options, Chapter - Popover menu window unindexed in the extension Menus by Dannii Willis:

Problem. The sentence 'The menu window is a g-window variable'   appears to say two things are the same - I am reading 'menu window' and 'g-window variable' as two different things, and therefore it makes no sense to say that one is the other: it would be like saying that 'Adams is Jefferson'. It would be all right if the second thing were the name of a kind, perhaps with properties: for instance 'Virginia is a lighted room' says that something called Virginia exists and that it is a 'room', which is a kind I know about, combined with a property called 'lighted' which I also know about.
Problem. The sentence 'The menu window is the main-window'   appears to say two things are the same - I am reading 'menu window' and 'main-window' as two different things, and therefore it makes no sense to say that one is the other: it would be like saying that 'Adams is Jefferson'. It would be all right if the second thing were the name of a kind, perhaps with properties: for instance 'Virginia is a lighted room' says that something called Virginia exists and that it is a 'room', which is a kind I know about, combined with a property called 'lighted' which I also know about.
Problem. The sentence 'The popover menu window is a text-buffer g-window spawned by the main-window'   appears to say two things are the same - I am reading 'popover menu window' and 'text-buffer g-window spawned by the main-window' as two different things, and therefore it makes no sense to say that one is the other: it would be like saying that 'Adams is Jefferson'. It would be all right if the second thing were the name of a kind, perhaps with properties: for instance 'Virginia is a lighted room' says that something called Virginia exists and that it is a 'room', which is a kind I know about, combined with a property called 'lighted' which I also know about.
In Chapter 1 - Initialisations, windows and values, Section - Definitions of properties and values in the extension Flexible Windows by Jon Ingold:
Problem. You wrote ''A g-window is a kind of container'  ', but that seems to say that some room or thing already created ('g-window variable', created by ''The menu window is a g-window variable'  ') is now to become a kind. To prevent a variety of possible misunderstandings, this is not allowed: when a kind is created, the name given has to be a name not so far used. (Sometimes this happens due to confusion between names. For instance, if a room called 'Marble archway' exists, then Inform reads 'An archway is a kind of thing', Inform will read 'archway' as a reference to the existing room, not as a new name. To solve this, put the sentences the other way round.)
Problem. In order to act on 'The g-window-positions are g-placenull, g-placeleft, g-placeright, g-placeabove and g-placebelow'  , I seem to need to give a new meaning to 'g-placeabove', something which was created by the earlier sentence 'The position of the popover menu window is g-placeabove'  . That must be wrong somehow: I'm guessing that there is an accidental clash of names. This sometimes happens when adjectives are being made after objects whose names include them: for instance, defining 'big' as an adjective after having already made a 'big top'. The simplest way to avoid this is to define the adjectives in question first.
Problem. In order to act on 'The g-window-types are g-proportional, g-using-minimum and g-fixed-size'  , I seem to need to give a new meaning to 'g-proportional', something which was created by the earlier sentence 'The scale method of the popover menu window is g-proportional'  . That must be wrong somehow: I'm guessing that there is an accidental clash of names. This sometimes happens when adjectives are being made after objects whose names include them: for instance, defining 'big' as an adjective after having already made a 'big top'. The simplest way to avoid this is to define the adjectives in question first.
In Section - Assigning properties to g-windows in the extension Flexible Windows by Jon Ingold:
Problem. You wrote 'A g-window has a g-window called direct parent'  , but 'g-window' is not the name of a kind of value which I know (such as 'number' or 'text').
 See the manual: 4.8 > New value properties
Problem. You wrote 'A graphics g-window is a kind of g-window'  : but kinds can only be made from other kinds, so 'a kind of container' is allowed but 'a kind of Mona Lisa' (where Mona Lisa is a specific thing you've already made), wouldn't be allowed. There is only one Mona Lisa.
Problem. You wrote 'A text-buffer g-window is a kind of g-window'  : again, kinds can only be made from other kinds.
Problem. You wrote 'A text-grid g-window is a kind of g-window'  : again, kinds can only be made from other kinds.
In Section - The main-window object, to spawn windows from in the extension Flexible Windows by Jon Ingold:
Problem. The sentence 'The main-window is a text-buffer g-window'   appears to say two things are the same - I am reading 'main-window' and 'text-buffer g-window' as two different things, and therefore it makes no sense to say that one is the other: it would be like saying that 'Adams is Jefferson'. It would be all right if the second thing were the name of a kind, perhaps with properties: for instance 'Virginia is a lighted room' says that something called Virginia exists and that it is a 'room', which is a kind I know about, combined with a property called 'lighted' which I also know about.
In Chapter 3 - I6 and Glulx Calls, Section - I6 for making a window in the extension Flexible Windows by Jon Ingold:
Problem. In 'The pending g-window is a g-window that varies'  , 'g-window that varies' is a contradiction in terms, as this is something that cannot ever vary.
In Chapter 5 - Writing to different windows, Section - Shifting and knowing where we are in the extension Flexible Windows by Jon Ingold:
Problem. In 'The current g-window is a g-window that varies'  , 'g-window that varies' is a contradiction in terms, as this is something that cannot ever vary.
Problem. The sentence 'The current g-window is the main-window'   appears to say two things are the same - I am reading 'current g-window' and 'main-window' as two different things, and therefore it makes no sense to say that one is the other: it would be like saying that 'Adams is Jefferson'. It would be all right if the second thing were the name of a kind, perhaps with properties: for instance 'Virginia is a lighted room' says that something called Virginia exists and that it is a 'room', which is a kind I know about, combined with a property called 'lighted' which I also know about.
In Section - Bordered g-windows in the extension Flexible Windows by Jon Ingold:
Problem. You wrote 'A bordered g-window is a kind of g-window'  : again, kinds can only be made from other kinds.
Problem. You wrote 'A g-border is a kind of g-window'  : again, kinds can only be made from other kinds.
In Chapter 9 - Text hyperlinks (for use without Basic Hyperlinks by Emily Short), Section - Initiating hyperlink handling in the extension Flexible Windows by Jon Ingold:
Problem. In 'The current hyperlink window is a g-window variable'  , 'g-window variable' is a contradiction in terms, as this is something that cannot ever vary.
In Chapter - Window definitions, Section - Windows with content in the extension Kerkerkruip Windows by Erik Temple:
Problem. The sentence 'The stats-window is a text-buffer g-window spawned by the main-window'   appears to say two things are the same - I am reading 'stats-window' and 'text-buffer g-window spawned by the main-window' as two different things, and therefore it makes no sense to say that one is the other: it would be like saying that 'Adams is Jefferson'. It would be all right if the second thing were the name of a kind, perhaps with properties: for instance 'Virginia is a lighted room' says that something called Virginia exists and that it is a 'room', which is a kind I know about, combined with a property called 'lighted' which I also know about.
Problem. You wrote 'The stat-header-window is a text-buffer g-window spawned by the stats-window'  , but the stat-header-window seems to be set equal to something in a complicated relationship with something else again, which is too much for me. Perhaps you're trying to do two things at once, and it would be clearer to write it as two sentences?
Problem. You wrote 'The powers-window is a text-buffer g-window spawned by the stats-window'  , but the powers-window seems to be set equal to something in a complicated relationship with something else again.
Problem. You wrote 'The powers-header-window is a text-buffer g-window spawned by the powers-window'  , but the powers-header-window seems to be set equal to something in a complicated relationship with something else again.
Problem. The sentence 'The inventory-window is a text-buffer g-window spawned by the main-window'   appears to say two things are the same - I am reading 'inventory-window' and 'text-buffer g-window spawned by the main-window' as two different things, and therefore it makes no sense to say that one is the other: it would be like saying that 'Adams is Jefferson'. It would be all right if the second thing were the name of a kind, perhaps with properties: for instance 'Virginia is a lighted room' says that something called Virginia exists and that it is a 'room', which is a kind I know about, combined with a property called 'lighted' which I also know about.
Problem. You wrote 'The inventory-header-window is a text-buffer g-window spawned by the inventory-window'  , but the inventory-header-window seems to be set equal to something in a complicated relationship with something else again.
In Section - Border windows in the extension Kerkerkruip Windows by Erik Temple:
Problem. You wrote 'The border-1-window is a graphics g-window spawned by the main-window'  , but the border-1-window seems to be set equal to something in a complicated relationship with something else again.
Problem. You wrote 'The border-2-window is a graphics g-window spawned by the stats-window'  , but the border-2-window seems to be set equal to something in a complicated relationship with something else again.
Problem. You wrote 'The border-3-window is a graphics g-window spawned by the stats-window'  , but the border-3-window seems to be set equal to something in a complicated relationship with something else again.
Problem. You wrote 'The border-4-window is a graphics g-window spawned by the powers-window'  , but the border-4-window seems to be set equal to something in a complicated relationship with something else again.
Problem. You wrote 'The border-5-window is a graphics g-window spawned by the stats-window'  , but the border-5-window seems to be set equal to something in a complicated relationship with something else again.
Problem. You wrote 'The border-6-window is a graphics g-window spawned by the powers-window'  , but the border-6-window seems to be set equal to something in a complicated relationship with something else again.
Problem. You wrote 'The border-7-window is a graphics g-window spawned by the main-window'  , but the border-7-window seems to be set equal to something in a complicated relationship with something else again.
Problem. You wrote 'The border-8-window is a graphics g-window spawned by the inventory-window'  , but the border-8-window seems to be set equal to something in a complicated relationship with something else again.
Problem. You wrote 'The border-9-window is a graphics g-window spawned by the inventory-window'  , but the border-9-window seems to be set equal to something in a complicated relationship with something else again.
Problem. You wrote 'The border-10-window is a graphics g-window spawned by the inventory-window'  , but the border-10-window seems to be set equal to something in a complicated relationship with something else again.
Problem. You wrote 'The border-11-window is a graphics g-window spawned by the inventory-window'  , but the border-11-window seems to be set equal to something in a complicated relationship with something else again.

[curiousdannii]

Ugh. Extension ordering should not be a problem. Maybe we could list Flexible Windows first?

[ektemple]

Yeah, the problem is the inclusion of Flexible Windows in Menus. I've rearranged the inclusions in story.ni now so that that shouldn't matter (commit 20bf7f0).

However, were the changes from your most recent commit working for you at all? For me, the status window shows up fine, but there's no menu content for anything but the top level. That content seems to actually be displayed in the main window, not a popup window. Also, after exiting the menu, you get an "Ok" message in the main that just runs inline with the content from the top-level menu (in the main window). Maybe the wrong version got committed somehow...?

By the way, you'll probably want to test your popover with Quixe and perhaps other terps before building it in as the default functionality. My memory is that text popover windows don't work correctly in Quixe (the "more" prompt from the window below appears--even if not needed--over the top of the popover), and perhaps other terps (http://www.intfiction.org/forum/viewtopic.php?f=7&t=7522).

[curiousdannii]

That's just strange, because your new order is essentially the same as the old one, except in regard to the other 3rd party inclusions, which didn't seem to be causing problems. Maybe we should list these at the very beginning:

Glulx Entry Points
Basic Screen Effects
Flexible Windows

It was all working when I last committed it (though I was only testing the text menu.) I'll take another look at it and use both menus.

I'll test with Quixe some more, but it's not a priority for Kerkerkruip. If we decide we want to use Quixe for our website we could put up a custom build perhaps.

[ektemple]

No, it is a definite change from the old order. Inform's handling of extension inclusions is buggy in very mysterious ways, so you can't base your logic on simple source order. I chose the order I did because we need to take into account the Glimmr extension, which will be the main build of the game, and it has to be ordered the way it is to work.

I'm not sure which menu is the other menu? Do you mean the menu at the title screen vs. the menu in-game? Because the menu at the title screen does not display a status line, whereas the in-game menu does.

I was saying that you probably don't want to release Menus as a standalone with that functionality if it doesn't work with Quixe. Popovers should be Kerkerkruip-only if they don't work in Quixe.

[curiousdannii]

I'll leave the extension ordering to you, you're the expert! I can't wait for the new I7. Well, unless it doesn't fix this!

Yeah I meant the main game menu.

My Menus extension is still in progress, but I may have to exclude the popover code from the final one. I'm thinking of trying some other popover directions, maybe they might work better somehow?

[ektemple]

If Zarf has fixed Quixe spec so that the spurious "more" prompt no longer appears when the height of the main window is 0 (i.e. when the popover's height is 100% of the root window's height), then it's probably OK. He seemed to recognize that this was an interpreter bug in this thread: http://www.intfiction.org/forum/viewtopic.php?f=7&t=7522

You could try a popover of 99% height, that might do it--as long as the author is not trying to change the background color of either window, that setup would probably be invisible for most use-cases, and hopefully won't cause Quixe to flash up a "more". But possibly Quixe will automatically draw a frame around the window? That would make it pretty ugly, but I'm not sure what the default CSS is. It would also be best to request the menu character input in the popover rather than in the main window (FW allows for directing input in this way).

[curiousdannii]

Looking over your comments again, some just don't make sense. I wonder if it was desynchronised at some point. But these ones remain. (Edit, actually now I'm seeing the no-menu-after-the-top-level problem...)

The main window is still be cleared, despite the popover window.

Is this in the IDE, or in Gargoyle/something else? The Windows IDE sometimes seems to like to pretend that it has lost its scroll back, but if you actually try to scroll, it adds it all back. (Should I report this as a bug?) Gargoyle behaves properly.

Because the menu at the title screen does not display a status line, whereas the in-game menu does.

This just doesn't make sense. We're actually calling the "open the status window" phrase twice in the before displaying rulebook!

It would also be best to request the menu character input in the popover rather than in the main window (FW allows for directing input in this way).

Can you think of any downsides of hacking VM_KeyChar() to add in the appropriate window when not specified so that Basic Screen Effect phrases work automatically?

[curiousdannii]

I believe that the text-going-to-the-main window problems are now fixed! 😄 The small amount of code I committed does not reflect the hours I spent trying to find the problem!

I still have no idea about why the status line isn't being shown. (Though didn't spend as much time on that.) From what I can tell the status window is open, but it just isn't being printed to.

Can you please take a look at i7/extensions#2 and tell me what you think?

[ektemple]

I think the issue is that there is no status line on the game's text introductory menu, so you'll have to explicitly open it (and close it) when you go from the introductory menu to one of the table-based menus. You can probably do this in a before displaying rule.

Does that sound right?

(Everything else seems to be working for me, so good work there!)

[curiousdannii]

But isn't that what the "open the status window" phrase does? The Before/after displaying rules in Kerkerkruip Windows.i7x should take care of it.

[ektemple]

Sorry, I'm at work and can't look at this closely, but it could it be that another "before displaying" rule has priority over the Kerkerkruip Windows.i7x rule and is preventing the latter from firing?

[curiousdannii]

No, none of the rules would stop it from running. (All before rules run unless one specifically tells it not to.) And as I said, I think it is actually open, just not in a usable way. When you get the time I'd appreciate it if you could take another look. It's not yet a super priority though, version 9 is still a little way off. (And I'll keep trying to figure it out myself too.)

[ektemple]

OK, the problem is that the status window needs to be opened before the popover window. They both split off the main window, and if you wait until after the popover is open to create the status window, the latter will split off of a 0-height window. One way to fix this would be by adding the starred line in Menus.i7x:

First before displaying rule (this is the switch to the popover menu window rule):
    if disable the popover menu window is false:
        now the menu window is the popover menu window;
        ***open the status window;
        open up the popover menu window;
        shift focus to the popover menu window;

I haven't made the change, though, since you might want to handle this some other way.

[curiousdannii]

Ohhh! Of course! Thank you so much for the diagnosis!

[mciul]

What is the status of this? I am missing the status window when viewing the menu from the intro window, but it shows when I use the "help" command while playing the game. I have glimmr extensions commented out.

[curiousdannii]

The status is that I've been slack and haven't fixed it yet! I'll try to make time for it this weekend.