xi-frontend / xi-term

A terminal frontend for Xi

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Create Widget Abstraction

wendivoid opened this issue · comments

Currently all xi-term layout happens within the Tui struct, as we add more component's this will get unwieldy.

My idea is to create a Widget trait and a InputResult enum. Inside the Tui struct there will hold a vector of widgets as well as the index of the active widget. as Tui reads input events it will pass them along the the active widget and re-render if required

pub trait Widget {

    fn handle_input(&mut self, event: Event) -> InputResult;

    // `TerminalWriter` is just a placeholder name.
    fn render(&self, w: TerminalWriter) -> io::Result<()>;
}

pub enum InputResult {

    // Keep Current widget active, and redraw.
    Continue,

   // Keep current widget active, but no redraw
    None,

   // Remove the currently active widget
    Close,
}

Widget

A Widget is simply an object that can handle input events and draw itself to a terminal.
Currently most of the render functions take W: Write as an argument this would have to be changed to a typed value(Since we ultimatly want a Vec and traits with generic members can't be turned into trait objects), this mean's we'll loose being able to render to any std::io::Write.

InputResult

The InputResult enum is how a widget pass's actions to the tui, for the current view widget this would always be the 'Continue' (or 'Close' if ^q is pressed). When a Command Prompt is implemented this would also be updated with a Command(EditorCommand) variant.

With these to abstractions we could cleanup the Tui struct and get it ready for adding, other components without cluttering things up too much.

After attempting to implement this, I think this is not the way to go. Storing the Editor as a widget in a Vec is more costly than first anticipated and since the Editor itself will have to be Stored outside the Widget area i think It would make more sense to drop this and work on refactoring the code some more to allow for better readability and maintainability. The first step i plan on making is pulling all the view/style handling code out of the Tui struct an into an Editor struct.