Discussion on accessing set_cursor in trait member function

[kdheepak]

Problem

With the new impl Widget for &mut App paradigm, it would be useful for having set_cursor on the buffer as well. This will make composition of widgets easier.

Currently, rendering an "input" widget needs to be done where you have access to the Frame to be able to set the cursor appropriately. e.g.:

let (main, input_area) = area.split(Layout::vertical([Min(0), Fixed(3)]))
...
let input_widget = tui_input::Input(text);
f.render_widget(input_widget, input_area);
f.set_cursor(input_area.x + 1 + text.len(), input_area.y + 1)

Currently I don't believe it is possible to do this instead:

impl Widget for &mut App {
  fn render(self, area: Rect, buf: &mut Buffer) {
    self.widget1.render(area, buf);
    self.widget2.render(area, buf);
    self.input_widget.render(area, buf);
    // unable to set the cursor on the buffer here
  }
}

Solution

Add a set_cursor in Buffer

buf.set_cursor(Some(x, y))

Additional context

This will negate the need for me to have a Component style architecture since users can compose reusable widgets.

[kdheepak]

Alternatively, we could add a draw (or a differently named function that takes Frame:

impl Widget for &mut App {
  fn draw(self, area: Rect, buf: &mut Frame) {
    //
  }
}

this will give each widget access to the "frame count" as well.

[joshka]

Ideally the render function would have a context param instead of just the buffer that would allow for carrying extra properties like this, but I think that ship has sailed without considering this as a rewrite.

[joshka]

I'm not 100% sure we should do this btw. It seems like an odd place to put a cursor when we have it already on Terminal and Frame.

[kdheepak]

What do you think about adding a new trait member function like render_with_context:

struct Context {
  frame_count: usize,
  cursor_position: Option<u16, u16>,
}

impl Widget {
  fn render_with_context(self, area: Rect, buf: &mut Buffer, ctx: &mut Context) {
    self.render(area, self.buffer);
  }
}

render_with_context can default to self.render(area, buf) so it would be backwards compatible I think.

[kdheepak]

Maybe it is not worth the maintenance effort + teaching people how and when they should use this, in which case feel free to close it.

[joshka]

Probably adding Buffer to the Context struct would be the right approach there instead of adding it as a parameter. But let's hold off on this one for a little bit as we've made a lot of changes recently to lots of things. Perhaps convert this to a discussion instead of an issue?

One approach to implementing this nicely without any Ratatui change is to set up some sort of shared Focus / Cursor state type, which any widget that needs to interact with those can add as a field (wrapped in the appropriate Rc/Arc/Mutex/RwLock shenanigans). Alternatively set up a specific mspc channel that accepts messages and deals with it at the end of rendering. Neither of those approaches requires a full blown component approach, just some shared code.

E.g.: (locks ommitted, but possibly necessary)

#[derive(Clone)]
struct CursorState {
  position: Rc<Position>,
}

struct App {
  cursor_state: CursorState,
  ...
}

struct MyTextField {
  cursor_state: CursorState,
}

impl App {
  fn render(self, frame: Frame) {

    frame.render_widget(MyTextField { cursor_state: self.cursor_state.clone() }, ...);
    ...
    frame.set_cursor(cursor_state.position.x, cursor_state.position.y);
  }
}

impl Widget for &mut MyTextField {
  fn render(self, area: Rect, buf &mut Buffer) {
    ...
    self.cursor_state.set_position((x, y).into()); // or something like this.
  }
}

I'd like to work out what that shared state looks like in https://github.com/joshka/ratatui-widgets/ so cursor and focus handling can be done across a bunch of interactive widgets. It feeds into the idea of letting widgets communicate back state and accept events.

https://github.com/sephiroth74/tui-confirm-dialog has an approach that works specifically using channels for getting back state and an approach for handling key events. I'm not sure if that's the right approach for building on top of yet, so I want to experiment more with several approaches based on this, particularly your work with components, async, events, actions, and with some other ideas (shared state, trait implementations, etc.)

[joshka]

A thought that came to me the other day on this, is that if you squint just a little, the following:

impl Widget {
  fn render_with_context(self, area: Rect, buf: &mut Buffer, ctx: &mut Context) {
    ...
  }
}

looks a helluva lot like:

impl StatefulWidget {
  type State = Context
  fn render(self, area: Rect, buf: &mut Buffer, ctx: &mut Self::State) {
    ...
  }
}

So arguably we have a version of the render with context already. It's just called something different.

[aramrw]

Is there any update on this?

[joshka]

There's various discussions in issues about what to do with the traits, no conclusion however.

We already have multiple mechanisms for making this work. Adding more would only make yet another way to do a thing.

1. struct YourWidget { cursor: Position } impl WidgetRef for &mut YourWidget { fn render_ref(&self, ...) { self.cursor = ... }
2. struct CursorState { position: position } impl StatefulWidget for &mut YourWidget { fn render(self, ... &mut state) { state.position = ...; }
3. struct YourWidget { sender<Position> } impl WidgetRef for YourWidget { fn render_ref(&self,...) { self.sender.send(...); } }

[kdheepak]

I didn't realise 1. worked. Do we have any examples of impl WidgetRef for &mut YourWidget?

[joshka]

I was mistaken. This should be impl Widget for &mut YourWidget and impl StatefulWidget for YourWidget.
See the example in #1147.

[joshka]

Rephrasing above to clarify my point a bit better. Not having a set_cursor method in the buffer isn't really a blocker to any behavior in Ratatui right now, it's achievable through several other ways mentioned (mutable ref widget, stateful widget with a value on the state, channels, etc.) These approaches however aren't necessarily ergonomic in their use (I think the channels approach is personally, and would be fine with the others too). Adding a cursor field to buffer seems less ergonomic to me than these workarounds.

In the absence of a simple and obviously correct implementation, and given this works fine but the problem is just that it requires two steps, I would tend to just leave it be rather than making the mistake of changing this to something which might be slightly better in some ways, but worse in others.