Will libcosmic offer a lower level procedural API in the future or are we committed to the Elm/MVU pattern?

[alshdavid]

Hi Team, first off thank you for your hard work on the Cosmic desktop environment. It's looking incredible and I love what you're doing!

I am interested in developing desktop applications targeting the new Cosmic desktop and have started my journey by learning from the current applications in the repos.

One thing that stuck out to me is that applications written using libcosmic are using the Elm-style MVU pattern for UI rendering.

I have worked with this pattern for a while and I do understand its utility, however it's not an approach I personally find enjoyable to work in for various reasons and it would likely be a significant detractor for my personal desire to write or contribute to Comic desktop applications.

I am 100% behind libcosmic offering and recommending an MVU architecture for the development of desktop applications. I would simply like that to be a library/framework that sits on top of a lower level API which is also accessible (something that can be built on top of - like the DOM API in the web world).

Would libcosmic offer a lower level procedural API for application development or is the Elm MVU approach is likely the only way going forward?

[Drakulix]

Hey there,

as you are probably aware, libcosmic is largely based on iced as the underlying toolkit.

Given iced has a very strong Elm focus in it's design and simply has no more low-level api (without abandoning half of the toolkit), it is very unlikely for libcosmic to ever promote something else, at least not for the foreseeable future.

But libcosmic is not the only way to develop applications fitting into the cosmic-ecosystem (though currently the most feature-complete one). There is work underway to enable slint to be usable just as well for apps fitting into the cosmic desktop: https://fosstodon.org/@slint/109461503881487882

Slint follows are much more traditional api approach and also has a few more language bindings (including Rust of course).

[alshdavid]

Hey @Drakulix, coming back to this almost a year later!

Once again I am enthused by the progress the team is making on the Cosmic desktop and want to find a way to contribute... but as soon as I start writing a libcosmic app, I am discouraged by the Elm-style API, with its boilerplate and indirection.

Have there been any changes in the ecosystem here? Perhaps another toolkit that can be used to build idiomatic native Cosmic applications?

EDIT: I wonder if it's practical for me to write a wrapper on top of libcosmic that exports a "lower level" web-like API 🤣

[mmstick]

You were simply mistaken about the level in which libcosmic's APIs are operating at. A procedural API is not necessarily lower-level than a functional one. In fact, the iced runtime and its views are operating on a much lower, leaner, and streamlined manner than traditional object-oriented APIs like GTK or Qt.

---

The iced runtime is a very lean event loop which has ownership of your application's struct—aka the Model. In each iteration of the loop, the runtime calls the view method of the Model to create a View. The View is a state machine whose purpose is both to describe the layout of the interface and how to draw it; and to be a streamlined pipeline for processing UI events and yielding any Messages from widgets in the View that they triggered. The View can efficiently borrow data directly from the Model because the View has the same lifetime as the borrowed Model.

Because the majority of the runtime is likely to be spent in drawing, the runtime will diff the layout and state of the View to detect when there is a need to redraw a node in the widget tree. The runtime will also cache certain elements between frames—such as images—to prevent the need to redraw them.

Once the View has been drawn, the runtime will wait for UI events—such as mouse and keyboard events—and process them directly through the View. Those events will be pass through various widgets which may emit any number of Messages in response. After the View has processed the UI event(s), the View is dropped and any received Messages will be passed through the Model's update method, which mutably borrows the Model.

The update method uses pattern matching to find the appropriate branch to execute (which is much faster than dynamic dispatch), and the programmer can then update the model while running any application logic necessary. Once the update method has completed, the next iteration of the loop begins.

So the main thread does not require an async executor as it only needs to manage one event loop, and its one application model. From the Iced book, it looks kind of like this

use magic::{display, interact};

// Initialize the state
let mut counter = Counter::default();

// Be interactive. All the time! 
loop {
    // Run our view logic to obtain our interface
    let interface = counter.view();

    // Display the interface to the user
    display(&interface);

    // Process the user interactions and obtain our messages
    let messages = interact(&interface);

    // Update our state by processing each message
    for message in messages {
        counter.update(message);
    }
}

---

To use GTK as a comparison, the main thread is managed by an async executor, as every widget is an object with its own event loop and state. GTK widgets behave internally the same as a Rc<RefCell<T>> type in Rust, which means that they require runtime garbage collection, and will continue to persist even if the widgets are not in use by the application. There isn't a singular event loop for handling application logic, so you are expected to pass cloned references of your widgets into the callbacks of every widget that needs to interact with their state. Which is prone to causing cyclic references when using strong references. This approach is fundamentally incompatible with Rust's borrow checker, so I would avoid staring into that abyss.

[alshdavid]

Nice explanation, I'll give it more thought - perhaps I am too quick to judge.

So the main thread does not require an async executor as it only needs to manage one event loop, and its one application model.

My previous experiences with this were that I ended up with a single struct as the entire application state and a giant enum to interact with values on the state. I found it difficult beyond trivial applications because of the lack of traceability and volume of events.

Perhaps libcosmic compartmentalizes this into "widgets" so each widget has its own state and "messages" enum that is separate to that of the main application - I haven't dug that far.

GTK widgets behave internally the same as a Rc<RefCell> [...] Which is prone to causing cyclic references when using strong references.

This is a fair criticism. With this hypothetical API:

let window = app.new_window(/* options */);

let button = Button::new();

button.append(TextNode::from("Click me!"));
button.styles.background_color.set("#000");
button.styles.text_color.set("#FFF");

let tx_on_click = button.add_event_listener("click");

app.spawn(async move {
  while let Some(ev) = tx_on_click.recv().await {
    println!("clicked {:?}", ev);
  }
});

window.append(button);

The internal state of each node would need to be managed via Rc<RefCell<T>>> assuming the async executor is single threaded. There is the issue of circular node references, though that could be avoided if nodes would be hard clones.

I'll think more about what you said, perhaps I'm just stuck in an older way of thinking about interacting with GUIs 😆

[joshuamegnauth54]

iced is difficult to understand at first and fairly low level, so you shouldn't blame yourself at all. 😺 One of the benefits of its design is that iced is extremely fast and clean. Message passing works well with Rust's borrow checker too as mentioned above.

My previous experiences with this were that I ended up with a single struct as the entire application state and a giant enum to interact with values on the state. I found it difficult beyond trivial applications because of the lack of traceability and volume of events.

I recommend reading through some of the source code for COSMIC's programs, such as the file manager or the various applets. The code is very readable for each as well as demonstrates patterns that can be useful in understanding iced. For example, the file manager, terminal, and editor each avoid a mega struct and long message enums by separating certain state into their own structs and messages. A tab in each of those apps is a struct with its own message. The main app passes messages to those tabs. Sub-state like tabs can also pass messages back to the main app as well.

There is also a book in the works for libcosmic which prove to be helpful as it's filled out.