imdaveho / tuitty-core Goto Github PK
View Code? Open in Web Editor NEWA cross platform, interoperable, simplfied terminal library that is meant to be wrapped by multiple languages.
License: MIT License
A cross platform, interoperable, simplfied terminal library that is meant to be wrapped by multiple languages.
License: MIT License
Problem to Solve
There are situations where a user might simply want to store exactly what is on the screen. Currently, the handling for \n
, \r\n
, and \t
characters simply moves the cursor -- there is no concept of a <TAB>
, <CR>
(carriage return), <LF>
(linefeed / newline).
Tasks
Store
to be aware of tabs, carriage returns, and linefeed characters in screen bufferProblem to Solve
If the user resizes the terminal window, there is nothing to detect how the contents should reflow, and more specifically, nothing to handle the changes in length and capacity for the contents in the stored screen buffer. It would also impact how we are recalculating internal cursor position, etc.
Tasks
Dispatcher
must init
already listening to input_handler
thread (ie. no need to call .listen()
InputEvent
these changes can be handled by the User
Description
Perhaps the target library simply wants the basics. Could we build a shared library that only contained the abstractions over Action
s?
Task
Action
s for each platform and osProblem to Solve
In most text editing use cases, there should be some visual indicator to shift from insert
mode to overtype
mode. Having the ability to change the look of the cursor can create that visual indication to a user. This can be changing the shape: box, I-beam, underscore or the blink frequency.
Tasks
Action
that changes the cursor shapeAction
that updates the cursor blink frequency (blink / noblink)Problem to Solve
Currently, we ignore carriage returns and prevent the buffer from scrolling down. This is in line with the idea that the screen is "a canvas". The assumption at the time is that "scrolling" can be implementing "virtually"--which is just a repaint of the existing screen with the next line.
However! While this works for the alternate screen, it is a different story on the main screen. In the main screen's case, we want to maintain typical console/terminal behaviour.
Tasks
Repro:
loop {
if let Some(evt) = stdin.next() {
match evt {
InputEvent::Keyboard(k) => match k {
KeyEvent::Char(c) => ...,
KeyEvent::Esc => return false,
},
InputEvent::Mouse(m) => match m {
MouseEvent::Press(btn, col, row) => match btn {
MouseButton::Left => {
... // <- gets skipped when press occurs because of escape sequence that returns false
}
}
}
}
}
}
Fix: check windows > parser > keyboard_events.rs
Problem to Solve
Scrolling puts too many things into the buffer and often, will flush due to the input buffer reaching capacity. This, not only causes unwanted behavior, but also needlessly renders too many things at once. Similar to issue #11 this will attempt to minimize the amount of "work" that flush()
has to do, and only output the necessary parts of the terminal that needs to change.
Tasks
^[ Pn T
(down) and ^[ Pn S
(up) )^[ Pn; Pn r
to set row start and row end as scrollable and ^[r
to reset )Description: On Unix systems, because the input buffer is not held in memory, there is no way to get the character underneath the cursor on the screen.
Task: Leverage the ScreenCache module on Unix to be able to do this.
Reason: Sometimes you want to toggle the background color of the current cursor location. (eg. to "mark" a cursor for multi cursor edits or to manually create a cursor instead of using the system one). This is not possible unless you can fetch the same char at the cursor location and print it with the new style.
Problem to Solve
When switching to the main screen: SwitchTo(0)
, it seems this is clearing the screen. Is this appropriate behavior?
Repro
SwitchTo(0)
from another screen that was created after Switch
Task
Problem to Solve
With prints
and printf
, we not only update the internal buffer, we also write to stdout
. This creates a moment when the cursor hops to the end of the printed content and leaves it up to the implementer to hop the cursor back to where it was. This little "flash" is not great, as it leaks out implementation details to the end user of the application.
Proposal
At one point we toyed around with having the screen redraw the contents of the buffer every time. This proved to be quite inefficient (as flushes are expensive). However, on thing we can do, is to make set_cell
public and to make render
into another Signal
. This way, there might be moments when you want to update the internal buffer, and when ready, render it on the screen at once, to prevent the cursor from hopping all around.
The goal is to render the output to the screen without the cursor going crazy. The implementation can vary. The above is the initial thought that can be tested.
Tasks
set_cell
in cells.rs
publicallyRender
SignalProblem to Solve
Right now, every time we call wincon::<some_action>
we have to pass in this vt-enabled
boolean value to notify the function whether or not the terminal in question supports ANSI-sequences or not. This creates a lot of repetition.
This also is the case for terminal defaults from get_mode
and get_attrs
. These can also be included.
Proposal
We initially made wincon functions accept a boolean parameter so that we don't have to call is_ansi_enabled
every time the function ran OR allocate additional memory in a struct to store the initial boolean value. This was an issue previously when we the only way to allow new threads to act upon the terminal was to create a new object to execute terminal commands. However, since moving to the Dispatcher pattern. We only need to create this once which is a lot more efficient.
This would then allow a single function call taking in only the parameters necessary for that function to work. This would simplify posix
and win32
calls in the actions
module.
This can also help with #8 and #13.
Tasks
is_ansi_enabled
into a structProblem to Solve
Currently, in multiple locations:
let handle = Handle::conout()?
ln 33, ln 69, ln 83, ln 93
)let handle = Handle::conin()?
ln 11, ln 19
)Handle is being called but never closed. This creates multiple hanging Handles that needs to be cleaned up.
Repro
Handle::
in project to find all locations where this is the caseTasks
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.