Add an example displaying usage of layouts

[Cassumbra]

A primary function of Ratatui seems to be aiding with splitting the terminal into separate parts with different widgets within. I'm having trouble figuring out the intended way of implementing a layout with bevy_ratatui due to how lifetimes work. Having an example which displays usage of layouts in any context would be very helpful!

[Cassumbra]

Hm... to clarify, what I've been trying to do is set up the layout as a resource in a setup system and then later use it, but that doesn't really work due to the lifetime of the rc involved (I think I'm saying all that correctly..?). It might just be that I need to have a singular system that sets up the layout/frame and draws everything there with things being split up only through helper functions. I'll give that a try.

[Cassumbra]

Having a conjoined system for rendering multiple widgets does indeed work. I've also tried splitting widget rendering into multiple systems. This does not work. The result is an awful flickering mess within the terminal.

If I knew what part of this was clearing the terminal and if I could handle that manually, I could potentially fix things.
That said, I'm not sure if what I'm doing even matters. Having one singular system where the terminal is constructed from different parts is probably just fine. Especially with the usage of widgets
Also, I just realized that I could probably consolidate some code by making the map rendering into an actual proper widget instead of a system that calls a helper function

Example of the code split into multiple systems:

pub fn render_map_ratatui (
    query: Query<(&Renderable, &Position, Option<&TemperatureDisplay>, Option<&PrecipitationDisplay>, Has<StrategicMapEntity>)>,
    //player_query: Query<(&Vision, &MindMap), With<Player>>,

    // TODO: Make default position without having player just be 0,0 or something
    player_query: Query<(&Position), With<Player>>,
    
    mut context: ResMut<RatatuiContext>,
    map_query: Query<(&MapSize), With<Map>>,

    layout: Res<LayoutTest>,

    //map_size: Res<MapSize>,
    order: Res<RenderOrder>,
    climate_debug: Res<ClimateDebug>,
    playing_state: Res<State<PlayingState>>,
) {
    //let frame = context.get_frame();
    let map_size = map_query.single().unwrap();

    let _ = context.draw(|frame| {
        let layout = layout.split(frame.area());

        let buf = frame.buffer_mut();

        render_map_proxied(
            query,
            player_query,
            &mut (layout[0], buf),
            *map_size,
            &order,
            &climate_debug,
            &playing_state,
        );

        frame.render_widget(format!(""), layout[0]);
    });
}

pub fn render_bottom_panel_ratatui (
    mut context: ResMut<RatatuiContext>,
    layout: Res<LayoutTest>,
) {
    let _ = context.draw(|frame| {
        let layout = layout.split(frame.area());

        frame.render_widget(format!("Blaaaaah!"), layout[1]);
    });
}

[kenianbei]

I was having a similar problem... since you can only call context.draw in one system, it bottlenecks you from tying into the normal ECS goodness. I'm working on a POC to add a component wrapper system for layout and widgets as a separate crate. Once bevy_ratatui and bevy_ratatui_camera gets updated to 0.30.0 I plan to release as a separate crate. This is the POC code:

https://github.com/kenianbei/bevy_ratatui_widgets/tree/temp/ratatui-0.30.0

[joshka]

My thinking when originally looking at this was that it might be worth investigating if it's possible to do something similar to the multi-world / subapp rendering ideas in core bevy where stuff is copied into a render world which can run on a schedule, while the rest of your systems can still run while rendering is happening. I never continued playing with that idea, but perhaps it's feasible?

[kenianbei]

I'd be interested in helping with anything that would make using ratatui easier in bevy. I've only used ratatui's predecessor tui-rs, this is the first time I'm using ratatui, as well as bevy. The main pain point is not being able to just add UI elements via bevy systems. This is just what emerged out of trying to get ratatui to play well with bevy.

If you have any suggestions or want to work on something via the widgets repo or another new repo, I'd would be up for collaborating or helping out with coding/testing. My game (still private) is starting to get somewhat complex now so it could be a good testing ground.

[kenianbei]

I did already hit a snag with tui-scrollview... because the scrollview implements it's own render function for inner widgets, it doesn't work with the bevy_ratatui_widgets system. The other downside with my crate is that it requires exclusive access to ratatui context. Some kind of plugin system might work better, maybe even as part of bevy_ratatui.

[joshka]

For some context - I created this lib as an experiment a while back, but handed it over to @cxreiff who now owns it as they're actually actively using this. I haven't touched it since then - this was mainly a directional idea for some of this. I think having a SubApp that owns the rendering part of things with state being managed by systems may be a way to do this well, but I haven't gone much beyond that thinking.

[kenianbei]

I'm playing around with the subapp idea, I've got a crappy vibe-code version working but will do some more work with it in the next few days.

[joshka]

Yeah, I threw codex into both this repo and the bevy repo and asked similar questions about each, then pasted the response from each back into the other to cross validate. Maybe worth creating a context where you have both repos available as the subapp stuff seems not well documented. Would be interested to see what you end up with either way.