-
Notifications
You must be signed in to change notification settings - Fork 273
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Input Expansion #81
Comments
I started down this road as well; I was approaching it by turning the winapi objects (keyevent and mouseevent) into vt sequences so that only the windows portion needs to be compiled on windows machines, but still run through unix-y csi handling to turn keyboard or mouse input events into a common "Event" enum similar to termion. I decided on this approach because windows is providing support for vt seqs in future cmd and powershell updates, so this wrapper would just be for backwards compatibility...so I didn't want to overcomplicate the codebase by having to maintain 2 separate input handling logic if eventually most new windows systems would simply be handling vt just fine...what do you think? |
Thanks for looking into this, as you might have seen I've moved the input logic to I prefer to have the WinApi code as well, maybe it is 400 more lines of code, but this is the goal of crossterm, that it supports all platforms even Windows 7 and 8. I've had a few people creating issues for those systems so there are still people using it. Also, all the other code currently has a WinApi + ANIS implementation and because of that, it seems a little odd to me to not support keybindings for those systems. So yes I still prefer having them both. If you have other problems or questions feel free to ask them. There are still some things that might be unclear in the code base. And some things that could be definitely done better. Also, if you got discord, let me know, this might be easier to communicate over some things. |
Any updates on this? If you are not working on this I will give it a try. |
Give me another day or so. Will try to post a PR or a gist. The latest update had a few merge conflicts.
|
Nice, yes, sure, no worries. Just making sure if there is progress. |
https://github.com/imdaveho/crossterm/tree/pr-upstream--add-input-events/crossterm_input/src/input Hey @TimonPost, I realize that there is actually quite a lot of work, and with the recent 0.6.* release, I actually get a lot of errors trying to run examples...I think it has to do with the folder placement. The work involved:
I'm also not too sure the direction you want to take this library (given how you modularized it and re-organized the folder structure) So I'm going to leave this code(most likely broken; definitely incomplete) as-is right now as reference. IF you want me to make a PR just to look at diffs LMK; else most of the changes are to /crossterm_input. My goal here is to effectively write a translation layer from windows consoleapi into VT sequences so that everything gets handled the same way. See attached diagram: Sorry that the code is a bit of a mess though...but I wanted to show progress and see how to divide and conquer once I realized that the work involved is a lot more than I had previously thought... |
This looks very interesting, I'll come back with a bigger story later if you don't mind, due to the fact I'm not at my PC now. I am more than happy by helping out solving the errors and making clear the direction of this crate, notice that I already created milestones and issues. I've got some plans to improve it even more, but some refactoring cannot be done until this is implemented. But I'll come back at this, great work! |
Okay 1. The direction of this crate
2. Error in the examples Because of this, we can't use those crates in our demonstration. I had two choices: 1, leave the example code and leave a note for enabling the raw mode, 2, move the The 3. Your idea 4. Other |
3. I want to translate the traditional Windows Console API into VT sequences such that the parsing for crossterm Events can go through a common, platform independent layer eg. parse_event() that consumes a buffer/stream of VT sequences. This is because Windows has already conceded that VT sequences are what most developers are used to, and have made updates to cmd and PowerShell to emit VT sequences instead of using ConsoleAPI objects. src 4. Because there is already a direction you're heading with crossterm; I don't want to make assumptions and design decisions that might conflict with what you want to accomplish with this library. I agree with most of the high level ideas you have, like making everything modular. Although I think some of those modules will most often be used together anyway and modularizing might not be the highest thing on my priority list. Also, in my exploration of input handling, I also realized that the work was starting to spill over to other considerations:
These would seem to overlap with your design vision, and therefore, I'd rather defer to you to integrate my work into how you want to proceed, taking into consideration my idea of standardizing input handling across windows and *nix systems. I'm more than willing to collaborate and contribute; but in this case, there are a few key pieces of functionality that I think would be more efficient if you saw it all the way through. Note: I am interested in getting this library to a v1 and beyond. I don't mind not being listed as contributor in this case, because I'm pretty sure I'll contribute down the line. How can I find you on Discord anyway? Note 2: I guess if you could give guidance on the bullets above regarding thread and mode handling, I can then merge in my input handling code for keyboard and mouse, no problem. 1. and 2. Yes, I think I'll have to dive deeper into the docs and review the release notes more closely. Eventually, I'll be more than happy to add to documentation and user guides/tutorials. |
Why did I split up everything? There were a couple of reasons:
Jup, I encountered the same problems you just listed. And with a little investigation, it is possible to do it right. Vision Continued Fortunately, due to my API-abstraction, I can change the whole back end (UNIX and Windows implementations) without changing anything to the API. Next, to that, I want something like this possible and I want to support input and mouse, key bindings like termion. As concerning to the input, I have no problems you making any API-changes. I don't have any major other plans for now, so I won't break your code again :). You can find my discord username here: https://daposto.stackstorage.com/s/FpVS06zCd1UAePx. So that we can communicate more easily. Here we can continue discussing the things who are not clear to you yet. |
I'm also very interested in this. I'm very new to rust so don't have much idea about this, but I have found xi-term's implementation very clean. https://github.com/xi-frontend/xi-term/blob/9038e2493d59890dad59887a0a167796edc9a1ea/src/core/terminal.rs Based on xi-term and termion I had come up with this generic api. use std::sync::mpsc::{self, Receiver, Sender};
use termion::event::Event;
pub type RenderTarget = MouseTerminal<AlternateScreen<RawTerminal<Stdout>>>;
pub struct Terminal {
stdout: RenderTarget,
pub terminal_events: Receiver<TerminalEvent>,
}
pub enum TerminalEvent {
Resize(Result<(u16, u16), io::Error>), // (width, height)
Input(Result<Event, io::Error>),
}
impl Terminal {
// some helper funcs. omitting constructors
pub fn clear(&mut self) -> Result<(), io::Error> {
write!(self.stdout, "{}", clear::All)
}
pub fn goto(&mut self, x: u16, y: u16) -> Result<(), io::Error> {
write!(self.stdout, "{}", cursor::Goto(x, y))
}
pub fn hide_cursor(&mut self) -> Result<(), io::Error> {
write!(self.stdout, "{}", cursor::Hide)
}
pub fn show_cursor(&mut self) -> Result<(), io::Error> {
write!(self.stdout, "{}", cursor::Show)
}
}
impl Write for Terminal {
fn write(&mut self, data: &[u8]) -> io::Result<usize> {
self.stdout.write(data)
}
fn flush(&mut self) -> io::Result<()> {
self.stdout.flush()
}
} Using it is also very clean. fn process_terminal_events(&mut self) -> Result<bool, io::Error> {
for term_evt in self.terminal.terminal_events.try_recv() {
match term_evt {
TerminalEvent::Resize(Ok((col, row))) => {
self.resize_editor(col, row)?;
return Ok(true);
}
TerminalEvent::Input(Ok(event)) => match event {
Event::Key(key) => return Ok(self.process_key_press(key)?),
Event::Mouse(me) => match me {
MouseEvent::Press(_, a, b)
| MouseEvent::Release(a, b)
| MouseEvent::Hold(a, b) => {
self.terminal.goto(a, b)?;
self.terminal.flush()?;
}
},
_ => {}
},
_ => {}
}
}
Ok(true)
} Theoretically you could also make the event be just With async/await and mio support it could be pretty generic. |
The discussion here is wide. Perhaps should we have more specific tracking issues ? |
Yea it is unfortunately, I updated this issue since this already a tracking issue. Currently there is a branch input_handling with a working implementation. It is already working and almost ready for release, only windows is having some problems with reading the key input, I am investigating that and doing some refactoring and cleaning up. This branch handles key, mouse special key inputs. |
There doesn't seem to be a "synchronous" implementation of event parsing in the input_handling branch, am I right ? I was expecting something like
Are users expected to wrap Is there a chat-like place where you'd be willing to discuss tests, implementation, etc. on this ? |
Please come over to the discord server I just created: https://discord.gg/K4nyTDB. |
fixed in #111 |
This is a tracking issue for the work what still needs to be done for reading input.
This feature should porovide support for the following Key Events
- winapi example code.
- Special key combinations
- Allow to capture mouse down, up and hold events.
- Allow seeing which mouse button is pressed.
The text was updated successfully, but these errors were encountered: