Is there a similar gui library to egui but it is retained?

help
1

egui feels the easiest to use however I am looking for something similar to egui in terms of syntax and it is retained instead of immediate?

2

All the retained-mode GUI libraries seem significantly more complex to use by comparison, and I would describe this as a hard domain generally. Though not new, I might recommend Igor Loskutov's article 50 Shades of Rust, or emerging Rust GUIs in a WASM world , featured in the May 3 edition of This Week in Rust . The landscape has not changed significantly since it's publication.

Happy hunting! Let me know what you settle on.

2 Likes
3

iced might better fit what you are looking for.

Unrelated rant...

Yes, this is a property of the GUI retaining widget state. It necessitates the introduction of callbacks or observers, push-pull or read-modify-write semantics for state updates, and in some cases a "virtual DOM" to facilitate cache invalidation.

An immediate mode API has a single source of truth for widget state owned by the application itself, and all widgets access it directly. The change of perspective with ownership obviates the observers, RMW, and caching, simplifying the API and how it is used.

This is a point of contention, as evidenced by comments on this series of articles which made the same observations:

4 Likes
4

The issue is that egui can offer its "simple" interface precisely because it's immediate. The way it supports updating the UI is to just re-run the code again. A retained version would also have to do that and moreover perform a diff with the previous version to know what to update. This is precisely what a retained approach wants to avoid and even more.

2 Likes
5

My feeling was that it is Xilem.

The progress might be not too fast, but they work hard on it, and the few examples I tested a few months ago look nice. Currently there are a lot of restrictions, e.g. only a few fixed size widgets with default colors, but I have the hope that might change in next year.

1 Like
6

Can you give me a very simple hello world example?

7

The examples in xilem/xilem/examples at main · linebender/xilem · GitHub are all quite small and not hard to understand. I think one of the smallest is xilem/xilem/examples/flex.rs at main · linebender/xilem · GitHub with a label and a inc and dec button:

// Copyright 2024 the Xilem Authors
// SPDX-License-Identifier: Apache-2.0

use masonry::text::ArcStr;
use masonry::widget::{CrossAxisAlignment, MainAxisAlignment};
use winit::error::EventLoopError;
use xilem::view::{button, flex, label, sized_box, Axis, FlexExt as _, FlexSpacer};
use xilem::{EventLoop, WidgetView, Xilem};

/// A component to make a bigger than usual button
fn big_button(
    label: impl Into<ArcStr>,
    callback: impl Fn(&mut i32) + Send + Sync + 'static,
) -> impl WidgetView<i32> {
    sized_box(button(label, callback)).width(40.).height(40.)
}

fn app_logic(data: &mut i32) -> impl WidgetView<i32> {
    flex((
        FlexSpacer::Fixed(30.0),
        big_button("-", |data| {
            *data -= 1;
        }),
        FlexSpacer::Flex(1.0),
        label(format!("count: {}", data)).text_size(32.).flex(5.0),
        FlexSpacer::Flex(1.0),
        big_button("+", |data| {
            *data += 1;
        }),
        FlexSpacer::Fixed(30.0),
    ))
    .direction(Axis::Horizontal)
    .cross_axis_alignment(CrossAxisAlignment::Center)
    .main_axis_alignment(MainAxisAlignment::Center)
}

fn main() -> Result<(), EventLoopError> {
    let app = Xilem::new(0, app_logic);
    app.run_windowed(EventLoop::with_user_event(), "Centered Flex".into())?;
    Ok(())
}

The easiest way to test it should be

git clone https://github.com/linebender/xilem.git
cd xilem
cargo run --example flex.rs

The calc.rs is also compact and nice, and they have a minesweeper example, which might be a separate crate. Actually, I have not followed the Xilem development in the last four months, as I was busy with other stuff and Xilem is still a bit restricted. But I will continue with Xilem soon, actually Xilem was the main reason why I started with Rust a year ago. Their Vello GPU drawing lib is very impressive and the basis for Xilem.

For detaill visit https://xi.zulipchat.com/

2 Likes
8

How does its cpu usage compare with something like fltk? From my understanding iced is not pure retained its a mixture of both and lets say if the app is in idle which one would use more cpu?

Lets say I made a very simple application with dropdown menues and some buttons. Which one would use more cpu if I am doing as simple as clicking on drop menues, clicking on buttons etc?

9

The comparison is basically the same in my experience. And that applies to any GUI toolkit you choose. Even VB6, tkinter, and the long-dead allegro have no CPU usage while idle.

What a bizarre question. Why would a GUI use the CPU if there is nothing to do?

I provided the link below in your other thread, but I guess it needs to be brought up again. And I'll quote the relevant part:

An obvious optimization to any IMGUI library is to do zero work if there is no input and no state change. This is trivial for an application to implement.

All tested IMGUI frameworks support "idle optimization". I verified it works and drops the GUI power cost to ~zero. Just like you would expect. If your UI is mostly static then the answer to "is IMGUI a battery drain" is unambigously no.

10

For me egui does this thats why.

11

Egui does not just decide on its own to draw or do anything else. Your code does that.

12

or the backend renderer might be doing this.

13

What backend renderer are you referring to? All of the ones I am aware of have the idle optimization.

14

Blue engine.

15

Never heard of it. If this is the crate you're talking about, I would suggest filing a bug for them: GitHub - AryanpurTech/BlueEngineEGUI: egui plugin for Blue Engine

edit: Yep, this crate ignores the repaint flag on EventResponse: BlueEngineEGUI/src/lib.rs at b7d2423ffa2f7b1f4c5f2c219ec37d903a77070f · AryanpurTech/BlueEngineEGUI · GitHub