#78 (comment)

I'll see if I can get set up to test on Windows. (unfortunately I'm not very used to C, C++, or Windows)

Don't worry about Windows support. Just Linux/MacOS should be good enough for this PR. You can remove what Windows support currently exists to get this working if you need to.

Later Windows support can be added either through this renderer or by using the older Windows Console API instead of escape codes.

Keep in mind that the SCons MinGW builds were failing before your PR. I didn't figure out a good way to handle those yet.

#78 (comment)

I'll see if I can get set up to test on Windows. (unfortunately I'm not very used to C, C++, or Windows)

Don't worry about Windows support. Just Linux/MacOS should be good enough for this PR. You can remove what Windows support currently exists to get this working if you need to.

Later Windows support can be added either through this renderer or by using the older Windows Console API instead of escape codes.

Ok, sounds good.

For the keypad, I was assuming I should set the application keypad mode (DECKPAM), and it definitely gets set because xterm itself can show that flag at runtime. But keypad keys with either the layer on my keyboard or xdotool (both of which work for SDL) just get through as single characters characters, with no escapes at all. Was there anything you had seen that I'm missing there?

Was there anything you had seen that I'm missing there?

You're more ahead of this than I am right now. I don't know what to try next. Application Keypad sounds right and I wouldn't know why it doesn't give escapes.

Ok, I'll look into it a little more but might have to leave that one.

Mouse support is in, and works on xterm, urxvt, gnome-terminal, and kitty. I didn't do extended coordinates.

I also added focus in/out events, and handling of requested pixel window size and window position (which like the requested colums and rows is not supported on all terminal enumators and is also up to the window manager).

I think the problem with the keypad is just that there aren't escape codes for the keypad digits, and that's what my keyboard is sending. As arrows, page up, page down, home, and end they will probably work fine but I don't think there is a way to distingish the keypad versions of those keys from non-keypad versions.

I'm hesitant to ask you for anything else since you've already done an excellent job.

I'm not sure how to feel about DOUBLE_CLICK_TIME, but I can't think of the best way to handle it. SDL seems to be missing a way to manually get the OS double-click time, and I want to avoid more platform specific code for this. I'm just saying this out loud in case I missed something simple, otherwise you shouldn't worry about it since it can be worked on later.

For input handling I'd like unknown inputs to be logged at the debug level instead of being silently ignored so that they're easier to track. The libtcod/logging.h header has TCOD_log_debug_f for this. These switch statements should at least have a default:.

I went through the same thing with double click time and found it in the SDL code but couldn't see any way to access it externally. The current value is the fallback SDL uses in SDL_MouseDoubleClickTimeChanged(). I guess we could also read the SDL hint SDL_HINT_MOUSE_DOUBLE_CLICK_TIME but other than that I can't think of anything else to do.

And sure, I can add the logging.

I also noticed a couple of annoyances related to key handling: firstly SDL_GetScancodeFromKey() returns zero for characters like ! that I guess don't normally have a dedicated key, so we lose scancodes for that where SDL itself would get them. Secondly right now the shift modifier works for letter keys (by checking for upper case) and could easily be added for function keys and probably arrows etc., but I don't think there is any way to get the terminal to report it for digits and punctuation. Both of those could be fixed if there is some way to look at the keyboard layout to see which characters are on the same key, but I didn't spot any SDL functions that would help.

I went through the same thing with double click time and found it in the SDL code but couldn't see any way to access it externally.

Don't worry about it then.

I also noticed a couple of annoyances related to key handling: firstly SDL_GetScancodeFromKey() returns zero for characters like ! that I guess don't normally have a dedicated key, so we lose scancodes for that where SDL itself would get them.

SDL considers ! as being the 1 key for both symbols and scancodes. This is the same with all keys which have multiple symbols where they use the non-modified key as the code. I can't think of a good way to handle this.

Just support the most common keyboard layout for now.

Do you think that getting the shift modifer for those keys critical? If not I'd prefer to leave out anything that makes assumptions about the layout, especially since it will just be a big lookup table in the code.

For mouse support, I notice the samples program always shows "OUT OF FOCUS" and tile position of 0, 0, but it does with the SDL2 renderer as well. (The xterm renderer also doesn't get the mouse buttons there but that's because the sample uses a direct SDL call.)

Should I set a c_pixel_to_tile_ (that does nothing) for the context?

Do you think that getting the shift modifer for those keys critical? If not I'd prefer to leave out anything that makes assumptions about the layout, especially since it will just be a big lookup table in the code.

To be the most compatible with SDL the keys will need to be changed to their non-shift key codes with the shift key modifier set, but right now I just want something that works at all. Large lookup tables are tedious to write and can be done later.

For mouse support, I notice the samples program always shows "OUT OF FOCUS" and tile position of 0, 0, but it does with the SDL2 renderer as well. (The xterm renderer also doesn't get the mouse buttons there but that's because the sample uses a direct SDL call.)

The samples are out-of-date. The C sample is switched over to contexts but isn't using the correct functions in the mouse sample. The C++ sample is more correct but relies on the SDL window.

Should I set a c_pixel_to_tile_ (that does nothing) for the context?

No, it already does nothing if left unset.

Ok, I think I'm done then. I did some more testing:

• Linux xterm: ok
• Linux gnome-terminal: ok
• Linux konsole: set terminal size doesn't work, otherwise ok
• Linux kitty: set terminal size doesn't work, otherwise ok
• Linux urxvt: bad colour handling, otherwise ok
• Linux built-in console: drawing works (with bad colour handling), input doesn't work at all (no idea why)
• OS X default terminal: unusably bad colour handling, input ok
• OS X iterm2: set terminal size doesn't work, otherwise ok

(I didn't bother testing setting window pixel size and position here.)

SSH seems to work fine.

So I'll mark this PR as ready. Let me know if you want me to rebase to clean anything up.