Textui reform (warning: long and full of C)

[Pete Mack]

I liked this one

Anything that cuts into vertical screen space is a problem on small screens. So it should be possible to suppress any titles

[Nick]

edit: Yeah, I decided to do it this way.
https://postimg.org/image/8iea5hvm1/

I liked this one

[t4nk]

Did a big, boring refactor of the frontend and merged curses stuff into textui2. Hopefully it works... Anyway, now textui2 is even with master.
The next step is restoring debugging stuff.

[t4nk]

OK, I did that. One term for one handler, no options. That also allowed to remove ~300 lines from the frontend and made it less mind-boggling.

https://postimg.org/image/532i3uzm3/

I guess the next thing to do is to fix various bugs and update textui2 to angband's master. It's 43 commits behind and 649 commits ahead

edit: now I don't like that terms are displayed as numbers in the GUI (top of the screen). I was thinking about using a two-letter abbreviations for them, like that:

https://postimg.org/image/hie6bfb2r/

That looks pretty cryptic, but no more cryptic than numbers, IMO, and there are tooltips for them... opinions?
I also wanted to try to display them as roman numerals instead of arabic, unfortunately, int_to_roman() is a static function

edit: Yeah, I decided to do it this way.

https://postimg.org/image/8iea5hvm1/

edit: Decided to revert it and use hexadecimal numbers instead. Angband's players are nerds anyway

[Nick]

Come to think of it, there should be no options. The player opens a term called, say, "Display player (extra)" and this is what he gets.

Now you say it, this is obviously the right thing to do.

[t4nk]

Is this the point where you could put the options for each terminal window type into an edit file?

Come to think of it, there should be no options. The player opens a term called, say, "Display player (extra)" and this is what he gets.
(I mean, there are options for choosing font, transparency, etc, but this is GUI options, not game options that live in '=' menu).
edit: this is how the gui menu looks like:

https://postimg.org/image/8x0g9pafp/

That will stay as it is.

[Carnivean]

Is this the point where you could put the options for each terminal window type into an edit file?

[t4nk]

OK, here my plan:
There should be a file "list-angband-terms.h" with contents like this:

ATERM(CAVE, "Main", 1, 1)
...
ATERM(PLAYER_BASIC, "Display player (basic)", 72, 24)
ATERM(PLAYER_EXTRA, "Display player (extra)", 80, 24)

I'll also add a file "ui2-term-wrapper.c", which should handle all angband_term stuff, such as registering handlers for terms and things like that:

/**
 * \file ui2-term-wrapper.c
 * \brief Handles everything related to permanent subwindows of Angband
 */

static struct {
    int index;
    char *name;
    int min_rows;
    int min_cols;
    struct angband_term aterm;
} aterms[] = {
    #define ATERM(a, b, c, d) {.index = ATERM_##a, .name = b, .min_rows = c, .min_cols = d},
    #include "list-angband-terms.h"
    #undef ATERM
};

(edit: or all of it could be in ui2-display.c)

Hardcoding sizes like that might seem bad, but note that over time they can be unhardcoded in a backwards compatible manner, just by setting min_cols and min_rows to 1 (since the smallest term that can be created is 1x1). We'll also lose the possibility to create two identical terms (e.g., two terms for messages), which I think is no great loss.
The upside is that frontends could be significantly simplified. They would create terms like that:

int min_width;
int min_height;
aterm_get_min_size(ATERM_PLAYER_EXTRA, &min_width, &min_height);
struct term_create_info info = {
    .width = min_width,
    .height = min_height,
    /* other things */
};
term t = Term_create(&info);
aterm_init(ATERM_PLAYER_EXTRA, t);

And that will register the handler for player_events.
Another upside is that it will be easy to bring back options for subwindows (in the '=' menu).
I'll think about it more, while I'm playing the Sangband comp Opinions welcome. BTW, I don't like the name "angband_term", better names are especially welcome Maybe "struct term_wrapper"?

[t4nk]

Beyond a certain size, I'd truncate the information to be shown to the size of the window, leaving the on screen material at the minimum size. There's a certain point where you can't see anything worth a damn anyway.

That's assuming that the size where they crash isn't quite large of course.

I mean the size in characters (font glyphs). The "Display player (extra)" subwindow (that some people do use, as I learned ) requires 80x24 characters. "Display player (basic)" needs 72x24... it would probably be better to enforce minimum size if people want to use those.

[Carnivean]

Beyond a certain size, I'd truncate the information to be shown to the size of the window, leaving the on screen material at the minimum size. There's a certain point where you can't see anything worth a damn anyway.

That's assuming that the size where they crash isn't quite large of course.

[t4nk]

Making decent progress:

https://postimg.org/image/40eauh38f/

Now, the problem is that additional subwindows make the game crash immediately when they're too small. That's because the new Term package doesn't tolerate printing off screen. An easy way around it is to make Term less strict... the proper way is to make additional terms adaptable, or at least print an error message ("Subwindow is too small!") when the user makes it too small...
I think I'll take a short break. Of course, when I say "I'll take a break" I usually don't take any breaks But I'll try anyway and in the meantime will think what to do with small terms...

[t4nk]

This thing I'm especially proud of:

https://postimg.org/image/tn9q8z69l/

That was already a feature of old SDL2 frontend, but I had to do it "by hand". Now do_cmd_view_map() is smarter and asks the frontend for desirable map size (full map, in this case). And it still knows how to scale the map Angband-style, if necessary.

[Nick]

I did the seconds pass over ui2-* files. At this point all the major systems of ui work (except for debugging stuff), and the game is playable.

https://postimg.org/image/tc42375uj/

There are certainly many bugs left, the frontend is not fully operational yet (no tiles, no additional subwindows) and the ui could use some optimizations (perhaps even diff-based optimizations, a la ui-term.c), but I think it's a major milestone. All in all, I was surprised by how well it went. I expected it to take a lot longer.

That is looking really good

[t4nk]

I did the seconds pass over ui2-* files. At this point all the major systems of ui work (except for debugging stuff), and the game is playable.

https://postimg.org/image/tc42375uj/

There are certainly many bugs left, the frontend is not fully operational yet (no tiles, no additional subwindows) and the ui could use some optimizations (perhaps even diff-based optimizations, a la ui-term.c), but I think it's a major milestone. All in all, I was surprised by how well it went. I expected it to take a lot longer.

[t4nk]

Maybe it looks like a hack from an engineer's perspective, but as far as design goes, I think it's reasonably elegant - the user is always looking at the top line of the screen anyway, and when a prompt is being displayed you don't need to read previous messages.

Well, from a user's perspective, "-more-" makes me press a ton of keys all the time, and most messages are not worth reading! "You hit the kobold" - what do I care? What would be good is to force pause on important messages ("*** LOW HITPOINT WARNING! ***"). I do have some ideas...

Under the new term stack model, I could see a case being made for each new term window being given a titlebar with the prompt

Great minds think alike! I did consider that (when thinking about tile picker). A term could perhaps have a header and a footer (similar to how menus have them). Those could be text, while the middle of the term could be tiles, or text with different font... it's a bit annoying to do, but not too much, so maybe
As it is, various menus and textblocks do tend to gravitate towards the prompt area:

https://postimg.org/image/vco26pl0p/

(BTW! What's the deal with using double spaces between sentences in various descriptions? Another old school thing, I guess...)