Tin
You can't parse terminal input, but a tin can! The cross-platform terminal input parsing library
17 Replies
that is beautiful pixel art
Thank you :)
Tin will be written in Zig, but will be compiled to a C ABI
Meaning c/c++ will be support too
With this ABI I also have the ability to support languages like Python, JavaScript, Go, Rust and such through bindings
Tin is simple with it's only goal being to provide extensive and cross platform terminal input. This allows you to avoid the most egregiously annoying process in building terminal apps
Especially on Linux this process can be super tedious, so skip all that. Why do it yourself when a tin can!
This project does back off #atleg's amazing input system, with minimal changes to create a unified api for Windows, Mac, and Linux
Oh forgot to mention tin also supports mouse input, with Windows this isn't as simple as a escape sequence, but to support it on Linux means support on Windows. Even if it does mean stretching what tin should be doing
Thinking about how I could show off Tin in a cool way...
Hm wait I actually have an idea
Let me mess around real quick
This is kind of the idea I have ended on
The colors aren't really what I care about here, but the actual ascii
More stuff would of course be added on to this demo
But I think it's neat for tin to showcase itself like this
The mouse demo would likely be a sort of game. Where you have sliders and boxes.
I was thinking you could have rgb sliders for changing the color of the boxes. You can pick up and drag the boxes around. And using scroll wheel will move all the boxes either up or down at once. Sort of like if you were scrolling the screen and it takes time for the boxes to catch up
This way the mouse can be tested pretty heavily and in a fun way
Alright input parser is up and running
100% didn't steal code from https://discord.com/channels/728958932210679869/1180540066188243024/1209964889708167209
That would be a shame 😅
Ok ok, well let me justify myself. I worked hard on atleg's input system :)
Tin does entirely back off this system. Although atleg is currently going through a process of being taken apart and broken into seperate modules. All of which will come together to make a TUI library. Kind of in the same way Mach works with it's modules. Atleg will at some point, be deleted. What will stand is the hard work I put into it. The work is just under new names, like tin!
Ok now back to tin.
Due to the scope of this project I find that setting terminal raw states and all that fun stuff isn't the job of tin. As this library will eventually be hooked up to another library which does handle that. I'm still thinking about this though. As I want Tin to work as a standalone library.
In other words is polling inputs the job of tin
And I think the short answer is yes
To keep things cross platform I think it is
I will only modify what I need to for polling input. Not turning the terminal into a raw beast. Just change what I need to
In this way it takes some burden off from the shoulders of a future TUI library
Useful resource, https://www.w3.org/TR/uievents-code/
Ok instead of doing polling on my end
I have a better idea
Tin is just focused on input parsing, it's up to the user to poll from the terminal and such
This avoids overcomplicating things a ton. Instead, for code examples I will just show users how to poll. For simple cases it's very simple. Doing it in a library like tin though would just be a bit too much for me. Especially where tin is going to be used in more then just a standalone library
Tin will still be cross platform, I need to implement some windows parsing stuff and then Tin will be done
Do not mind this file
Here is a minimal linux example of using
tin
Polling input events isn't the job of tin. This task is something I'd expect someone working with the terminal at a low level to implement. This is Zig not Python, my goal isn't to abstract everything all at once. Tin will be used in conjuntion with other tools to form one big terminal abstraction library. Standalone though, it's simply something to assist with input parsing.
Terminal input parsing is no easy task, so much crap goes into it. Seriously. Just input parsing on Linux (+ all my tests) is over 1000 lines of code
I'm not sure how much of my code I can reuse for Windows though because I'm not too sure how Windows and Linux differs there.
I may have to look at Newtrodit's source code... @earth's god is there any major differences in the key codes emitted on Windows and Linux? I'll end up testing this tomorrow so you don't have to get back to me if you don't want to.
Regardless I see adding Windows support as a huge task. I worked very hard to make a amazing and pretty much full coverage of all keyboard events on Linux
Doing this on a platform I have really no clue about will be a bit hard...
There are quite a lot of differences
For normal keys (numbers and letters) it's the same but for special characters/combinations the thing changes then
Is there a list of special characters somewhere? I want to make sure I support as much of the keyboard as I can
Never mind this seems to be fine https://learn.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences
Console Virtual Terminal Sequences - Windows Console
Virtual terminal sequences are control character sequences that can control cursor movement, color/font mode, and other operations when written to the output stream.
As far as key combos go I think I just need to test that and figure it out myself that way