Version `0.2.3` of Crossterm will have API braking changes. If you are reading this and you version whas autmaticly incremented to the new version, there will be some broken code. An Quiqe solution? no unless you did not used this crate that much. If it is important to keep running you code and you don't want to spend some time to fix the errors I recomend you to keep using version `0.2.2` because in version `0.2.3` alternate screen and some other features are introduced. And if you are not using any of these feature just downgrade. If however you want to have the newest version you can check the [upgrade manual](link) on how to upgrade to te new version. Check [changelog](link) why thise Api braking changes where nessairly.
This documentation is only for Crossterm version `0.2.3` if you have an older version of Crossterm I suggest you to check the [Upgrade Manual](link_to_manual) for more infomation about how to upgrade to a new version or I suggest you to checkout the [examples](link) for each version of Crossterm.
This crate supports all unix terminals and windows terminals down to windows XP but not all of them have been tested.
If you have used this library for an terminal other than the above list without issues feel free to add it to the above list, I really would appreciate it.
Crossterm is using ANSI escape codes by default for both unix and windows systems.
But for Windows it is a bit more complicater since Windows versions 8 or lower are not supporting ANSI escape codes. This is why we use WinApi for those machines. For Windows 10 ANSI codes will be the default.
This libary is not stable yet but I expect it ot not to change that mutch anymore.
And if there are any changes that affect previous versions I will [describe](link_to_upgrade_manual) what to change when upgrading Crossterm to an newer version.
I want to be able to do something based on the clicks the use has done with is mouse.
- Handling key comn
I want to be able read key combination inputs.
- reading from the console.
I want to be able to read the input of the console.
- Error handling
Currently I am not doing that mutch with returend errors. This is bad since I suspect that everyting is working. I want to mange this better. When you build this crate you will see the warnings about not used return values. This is what needs to be improved.
Also I want to have tests for this crate, and yes maybe a little late :). But I find it difficult to test some functionalities because how would you ever test if the screen is indeed int alternate, raw modes or how would you ever test if the terminal cursor is moved certainly.
If you would like to contribute to Crossterm, than please design the code as it is now.
For example a module like cursor has the following file stucture:
- mod.rs
This file contains some trait, in this case `ITerminalCursor`, for other modules to implement. So that it can work at a specific platform.
- cursor.rs
The end user will call this module to access the cursor functionalities. This module will deside withch implementation to use based on the current platform.
- winapi_cursor
This is the cursor trait (located in mod.rs) implementation with winapi.
- ansi_cursor
This is the cursor trait (located in mod.rs) implementation with ANSI escape codes.
The above structure is the same for the terminal, color, manager modules.
Why I chose for this design:
- Because you can easaly extend to muliple platforms by implementing the trait int the mod.rs.
- You keep the functionalites for different platforms speperated in different files.
- Also you have one API the user can call like in the `cursor.rs` above. This file should be avoided to change that mutch. All the other code could change alot because it has not impact on the user side.
I higly appriciate when you contributing to this crate. Also Since my native language is not Enlishe my grammer and sentence order will not be perfect. So improving this by correcting these mistakes will help both me and the reader of the docs.