Expanding the Screen interface

[jaypipes]

what do you think about adding a few methods to the Screen interface? specifically things like ShowCursor and SetCursorPosition? That would help me avoid passing in a *TerminalScreen instead of a Screen interface type to my render methods...

[aymanbagabas]

I thought about this. However, I envision the Screen interface to be the minimum interface for a cell-based UI regardless of its "backend". In this case, the terminal is the backend where escape sequences control many aspects of how things are presented.

I have this idea where I want Ultraviolet to run on IoT devices like ESP32 and others via TinyGo. In such cases, you don't have a cursor moving around to render cells, nor escape sequences that control the terminal state. Though, I thought about coming up with something like a uv.ScreenController similar to http.ResponseController that extends a Screen with cursor and other methods and error if the screen doesn't implement them 🤔

[jaypipes]

@aymanbagabas are you thinking about moving TerminalScreen.ShowCursor and related methods to Terminal then? Or maybe Console?

[jaypipes]

@aymanbagabas jaypipes/gt@df891f6 :)

[aymanbagabas]

Yes, my thought was instead of this being an interface, it would be a concrete type and each method works by type assertion and error if the original screen doesn't implement the function being called.

For example:

type ScreenController struct {
    scr Screen
}

func (c *ScreenController) SetCursorStyle(st uv.CursorStyle, blink bool) error {
    if s, ok := c.scr.(interface{ SetCursorStyle(uv.CursorStyle, bool) error }); ok {
        return s.SetCursorStyle(st, blink)
    }
    return uv.ErrNotImplemented
}

[jaypipes]

ScreenController being an interface (in jaypipes/gt/types) works best for me as a consumer of these things. *ultraviolet.TerminalScreen implements jaypipes/gt/types.ScreenController and so there's no need to add a ScreenController interface type to ultraviolet itself...