Textui reform (warning: long and full of C)

[t4nk]

Also, reposting some code here cause as it is gcu doesn't feed angband with the proper encoding for function keys and numeric-keypad keys.

Thanks! That's already done. I think these old school magic numbers for numpad keys don't even work... I borrowed (even more magic) control strings from DCSS
(edit: well, shift-running with numpad still doesn't work... and I suspect it's not possible to make it work, at least, not in a remotely portable, to different terminals, manner. This is what you get for using software that literally emulates hardware which hasn't been in use since the early Triassic period! This stuff just didn't have numpads!)
(edit: wait, I found some pictures and VTE100 did have a numpad! I don't know... patches welcome )
edit: Well, I made numpad running work in xterm... but not in other terminals. Whatever...

[t4nk]

Umm, the current implementation (and I haven't really looked that code, so I am talking as a user fully here) is nice.

I know... I have looked at the code, literally all of it The current Angband's ui is the terminal ui, through and through.
Writing shell scripts for configuring the game is undoubtedly clunky... Although, it does offer much better control over what is displayed. All in all, I think that's nerdy enough for people who are into these kinds of things

edit: And I don't think balance_subwindows() does a very good job at resizing. For example, on my laptop:

https://postimg.org/image/mtommuqf1/

That would work with a bigger monitor, but on a laptop, it just makes the map too small. Basically, I don't think that a really smart algorithm is possible here at all. Not even in GCU (despite the rest of the ui catering to its needs), and certainly not in textui2...

[redlumf]

Also, reposting some code here cause as it is gcu doesn't feed angband with the proper encoding for function keys and numeric-keypad keys.

(just search for the comment /* keypad keys */ on code)

/* keypad keys */
		case 0xFC: i = '0';mods |= KC_MOD_KEYPAD; break;
		case 0xFD: i = '.';mods |= KC_MOD_KEYPAD; break;
		case 0xC0: i = '\b';mods |= KC_MOD_KEYPAD; break;
		case 0xDF: i = '1';mods |= KC_MOD_KEYPAD; break;
		case 0xF5: i = '3';mods |= KC_MOD_KEYPAD; break;
		case 0xE9: i = '5';mods |= KC_MOD_KEYPAD; break;
		case 0xC1: i = '7';mods |= KC_MOD_KEYPAD; break;
		case 0xF4: i = '9';mods |= KC_MOD_KEYPAD; break;
		
		case KEY_F(1):i=KC_F1;break;
		case KEY_F(2):i=KC_F2;break;
		case KEY_F(3):i=KC_F3;break;
		case KEY_F(4):i=KC_F4;break;
		case KEY_F(5):i=KC_F5;break;
		case KEY_F(6):i=KC_F6;break;
		case KEY_F(7):i=KC_F7;break;
		case KEY_F(8):i=KC_F8;break;
		case KEY_F(9):i=KC_F9;break;
                case KEY_F(10):i=KC_F10;break;
		case KEY_F(11):i=KC_F11;break;
		case KEY_F(12):i=KC_F12;break;

[redlumf]

Yeah, I think I'll disable terminal specific signals, that will also free up additional keys...

Well, the question is, how to handle that? There are up to 13 terms potentially present on screen that can change sizes (like, main map, sidebar, monster list, object recall - that kind of stuff). Don't think that would work satisfactorily with any kind of "smart" algorithm. Suggestions are welcome, though

Umm, the current implementation (and I haven't really looked that code, so I am talking as a user fully here) is nice. If terminal has room for 2 windows, put up 2 windows. If it has for 3, let's go with 3. Room for 4, 5, cool. I've never messed with specifying what each (sub)window should show. The current gcu defaults (variable on size) are fine with me.

I end up with a full screen terminal with a font size that I find comfortable and that's it.

[t4nk]

Yeah, I think I'll disable terminal specific signals, that will also free up additional keys...

It would be just nice to have resize handling.

Well, the question is, how to handle that? There are up to 13 terms potentially present on screen that can change sizes (like, main map, sidebar, monster list, object recall - that kind of stuff). Don't think that would work satisfactorily with any kind of "smart" algorithm. Suggestions are welcome, though

[Pete Mack]

On tablets, ctl-ccc has value, because there are a limited number of easy-to-use keys in hjkl (rogue) mode. And those are pretty much meaningless in a standalone (e.g. Windows) app anyway. For mage especially I bind a whole lot of keymaps to control characters.

[redlumf]

Well, I think it's mostly done... Question (to players).
Do you use some "special" terminal abilities while playing? Do you ever suspend Angband (using Ctrl-Z)? Do you expect Ctrl-C to do anything interesting? Do you change the size of the terminal while playing?
All that stuff seems utterly useless to me. Thoughts?

No ctrl-z/ctrl-c for me. I don't use them. ctrl-c is a no-no, cause you might hit it by mistake and lose progress. Ctrl-z would be more forgiving if average Joe would knew that 'fg' brings the suspended command to the foreground. Since we can't expect that from average Joe, I think it's a no-no too. (I obviously can live with current implementation that has a working ctrl-z )

I don't change terminal size mid-game. I guit, resize, rerun game. It would be just nice to have resize handling.

[t4nk]

Well, I think it's mostly done... Question (to players).
Do you use some "special" terminal abilities while playing? Do you ever suspend Angband (using Ctrl-Z)? Do you expect Ctrl-C to do anything interesting? Do you change the size of the terminal while playing?
All that stuff seems utterly useless to me. Thoughts?

[redlumf]

I prefer gcu over other implementations. I think it's subconsious. It gives me the "old school" feeling and I probably have Angband as old school in my mind.

[hjklyubn]

I don't really know where to start answering this.

I think you missed the subject of this discussion entirely. The question I was answering was why do terminal players prefer playing in a terminal. As a terminal player I explained why I prefer playing in a terminal. My reasons apply to me, and other people like me. They obviously need not apply to everybody. Nobody is proposing removing all frontends except the terminal frontend.

[Pete Mack]

@debo-
Yeah, but the code doesn't work anymore, and no one seemed particularly interested. It is kinda limited in value because it needs identical window size, executable version, and certain other options.
ttyrec is a lot more useable.

[t4nk]

Basically, the terminal is already really good at displaying rectangular grids of characters; why would I want to use any other tool to do it?

Because maybe this other tool lets you use numpad fully? (including shift-running). That seems to be a popular way to play the game
Does anyone have numpad working with GCU? (with numlock off).

edit: I stole some code from DSCC. Now numpad works... the thing is, numpad keys 1-3-7-9 are actually "page down", "page up", "home" and "end" (that is, terminals think so ). That means that real "page down" and "page up" also move @ diagonally... Should it work like that?
Shift-running won't work with numpad it all - as far as I can tell, that's simply impossible.
edit: LOL! I see that Angband defines macros for KC_PGUP and friends... ok then.

[t4nk]

This talk about recording game is pretty interesting. I think Angband had something like that at some point? That doesn't seem very difficult - an input stream + RNG seed... Pete, you were working on that some time ago, right?

[debo]

I don't really know where to start answering this. Maybe by explaining that no one knows how to use a command line? Or that this command by itself isn't enough to start a recording on most desktop setups (you have to be on Linux, have already installed this program...)? Or that it is much easier to configure further options on a GUI than command line? Or that you are only addressing the "recording" part, while there is much more infrastructure for sharing true videos with the world (e.g. Youtube)? And, does that thing even support sound? And multiple terminals, which is how most people play Angband nowadays? Can you edit the recordings it produces without a degree in reverse engineering?
Nah, I'll just do what you did and go with a smug one-liner that is technically true but ignores most of the issues:

Typing 'recordmydesktop' requires 2 fewer keypresses.

As someone who has recorded a few videos of *band (Sil) game sessions, GCU + ttyrecs are still hugely helpful because they are easy for other players to record and transmit, and for me to replay and cast -- which I have done several times.

GCU additionally makes it a lot easier to share your games in realtime with other players using live terminal sessions on things like termcast.org -- angband is already approximately 10 years behind DCSS in the "come watch me play" department, and forcing me to have uninterrupted 2mbps up with low latency to stream on something like twitch means that this is basically never going to happen for angband if GCU disappears.

[fph]

Yes, I'm pretty sure typing 'ttyrec -e angband' is easier than setting up video recording software. Is angband only for computer-illiterates?

I don't really know where to start answering this. Maybe by explaining that not everyone knows how to use a command line? Or that this command by itself isn't enough to start a recording on most desktop setups (you have to be on Linux, have already installed this program...)? Or that it is much easier to configure further options on a GUI than command line? Or that you are only addressing the "recording" part, while there is much more infrastructure for sharing true videos with the world (e.g. Youtube)? And, does that thing even support sound? And multiple terminals, which is how most people play Angband nowadays? Can you edit the recordings it produces without a degree in reverse engineering?
Nah, I'll just do what you did and go with a smug one-liner that is technically true but ignores most of the issues:

Typing 'recordmydesktop' requires 2 fewer keypresses.