Current state of Agui

[pmjobin]

Hello,

I was planning to write a barebone Flutter clone in Rust to help me develop user interfaces for my hobby projects when, during my initial research, I learned about the existence of Agui, which appears to go in a very similar direction to what I had intended.

I don't mind coming up with my own user theme and set of widgets since many of those required by my projects need to be custom-built anyway. While browsing the Agui source code for examples, I found implementations for the Button and TextField widgets, except those appear to depend on types that were deprecated a few months back (such as PaintContext & Layout). I'd like to familiarize myself better with Agui by restoring the functionality of these two widgets as an exploratory step. How would you suggest I go about this? (i.e. Where was the PaintContext functionality moved? etc)

Would you rate Agui in its current state as complete enough to implement a decent set of interactive widgets (e.g. sliders, combo box, scrollbars, tabbed views, etc) and build a moderately complex desktop application above it all? And if not, what are the missing bits and pieces?

Thanks for your help,
P-M

[Stumblinbear]

Unfortunately the answer is not so simple as you might hope. I don't have a ton of time to pump into this due to work obligations and I'm pretty far into a sizable rework of data flow, event handling, and yanking out morphorm in favor of direct layout calculations, along with decoupling windowing and rendering from the engine itself.

A lot of that work has already been done! Inherited widgets are working quite nicely, winit windowing is in its own crate, as is the vello integration, but these are only a month old at best so need some general work. Heck, the vello integration doesn't even properly support textures, yet, but it's on my relatively short todo-list.

My current priorities are unfortunately blockers for any actual use-cases. I need to re-implement mouse events/gestures, focusing, and keyboard event handling. All of these relied on inherited widgets being completed so I can get them into the tree without hacks, and inherited widgets took me a good long time to figure out a way I was happy with implementing them.

Once that's done (or at least in a usable state), re-implementing the controls (I likely will yank out Button and TextField in favor of significantly more generic, composable widgets) and adding new ones is absolutely the next priority. Beyond that is improving the graphical capabilities of the painting system, even if vello doesn't properly support what I need it to do just yet.

As a more general subject, I'm trying to figure out how I actually want users to build interfaces. The build! macro is very nice, but requires all widgets to derive Default which I know many will be unable to do. If any widgets in build! doesn't support Default, then the whole call is impossible since it'll try to include ...default() which Rust isn't happy about. I'm trying other conventions such as .with_child(), but am still unsure how I feel about it, as I don't know how difficult it will make actually reading complex interfaces.

Even further down the line: hot-reload is a stretch goal, but haven't put a ton of time looking into it just yet.

At any rate: with the pace I'm going on this, I don't see the things you need being implemented any time in the next few months considering I'm working alone, but it'll happen eventually!

Side note: "barebones flutter" is actually surprisingly difficult! I'm actually around two years into this, working on it on-and-off, and I'm still not to what I would consider "barebones." (Though that's definitely completely my fault. I've been a stickler for performance and ensuring I uphold some invariants so that the engine can optimize rebuilds as much as possible). I'd put that landmark following proper mouse, focus, and keyboard handling.

[pmjobin]

First and foremost, a massive thank you for your quick and comprehensive response.

In regard to your side note, I absolutely agree that calling it "barebone" is a misnomer. I'm fully aware of the monumental effort it takes to reimplement Flutter (even if it's just a modest chunk of it) in any language, let alone idiomatic Rust. Therefore, I was pumped to come across your diligent work on this. It's worth noting that some voices online had previously dismissed the idea of crafting a Flutter-like toolkit for Rust, citing the object-oriented nature of Flutter and the unique characteristics of Dart as blockers. However, your work on Agui seems primed to prove the doubters wrong! Out of all the ongoing efforts to create a native GUI toolkit tailored for Rust, yours displays the most promising potential in my opinion. Having dabbled in various GUI toolkits in the past (you name it, I've likely tinkered with it), I must admit that Flutter remains one of the most pleasant development experiences I had. Consequently, I'm eagerly looking forward to what Agui might achieve.

With that said, I genuinely wish I could contribute to this remarkable effort. However, I must confess that I'm still a relative newcomer to Rust. While I'm working on transitioning from my C++ background and immersing myself in Rust's ecosystem, I recognize that there are certain ingrained habits I need to shed before I can confidently produce elegant Rust code. Simply put, I'm not yet at the proficiency level where my contributions could make a significant impact on this project. Nonetheless, I'll be closely tracking its progress and have every intention of adopting it at a later stage. Hopefully, my abilities with Rust will have slightly improved by then so that I might be able to help you in some capacity.

Wishing you the best of luck with this project, and looking forward to future interactions!

[Stumblinbear]

It's worth noting that some voices online had previously dismissed the idea of crafting a Flutter-like toolkit for Rust, citing the object-oriented nature of Flutter and the unique characteristics of Dart as blockers.

I've come across that sentiment previously and definitely see where they're coming from! It requires an unfortunate amount of dynamic dispatch (unavoidable, but still more than I'd like), and all widgets must be reference counted since all widgets have the capability of rebuilding themselves at any time (the engine must be able to refer to it directly). This means when building your UI, all widgets need to be wrapped in Widget::new(children), but I'm working out ways to hide that from the user (build! or .with_child).

With that said, feel there's a case to be made that for sizable interfaces the benefits of not updating the entire tree when rebuilding far outweighs the downsides of DD. Though it does lock agui out of some embedded environments.

Some of flutter's implementation has to be reworked to fit Rust's coding style, though things have worked with few deviations thus far. Heck, the whole Flex implementation was essentially copied 1:1\!

[pmjobin]

Hey there, I wanted to discuss with you about a specific issue I've been grappling with pertaining to Flutter on Rust.

One of the key factors in how Flutter efficiently handles rebuilds relies on Dart's implementation of the keyword const.

For instance...

class Foo extends StatelessWidget {
  const Foo(this.label, {super.key});

  final String label;

  @override
  Widget build(BuildContext context) {
    print('Building Foo($label)...');
    return Text(label);
  }
}

When you create an instance of const Foo, the "Building Foo()" message appears just once (coinciding with the initial build of its parent widget). As a result, the entire subtree under const Foo (even if it's potentially more complex than this trivial example) won't undergo any additional rebuilds when the parent itself is rebuilt.

Coming from a background in C++, this behaviour closely resembles the static const storage specifier.

#include <iostream>
#include <string>

struct Foo {
	Foo(const std::string& label)
		: label(label)
	{
		std::cout << "Creating Foo(" << label << ")..." << std::endl;
	}

	std::string label;
};

void build() {
	std::cout << "Building..." << std::endl;
	static const auto foo = Foo("foo");
}

int main() {
	build();
	build();
	build();
	build();

	return 0;
}

Output:

Building...
Creating Foo(foo)...
Building...
Building...
Building...

However, Rust, while highly capable, seems to be more stringent in what it permits to be declared as const. Anything that involves allocating memory on the heap appears to be off-limits. For example, using str is acceptable, but not String. Clearly, this poses some limitations. I'm curious to hear your thoughts on this. Could a crate like 'lazy_static' (https://crates.io/crates/lazy_static) possibly help with this issue? I apologize if this question seems basic; I'm still in the process of learning Rust. Thanks!

[Stumblinbear]

So I've actually already thought about this particular issue and have some ideas for how to get a similar system in place. It's mostly implemented, actually, just needs some additional work to fully expose the functionality and make it easier for devs to use.

The engine stores a map of all widgets that it has seen before so that it can yank them into other parts of the tree if they're duplicated or shifted about the tree, this would just be a matter of making a single Rc of const Widgets that are returned from your build functions and the engine should handle the rest already (to an extent!). This is already functional for widgets that are passed down the tree, for example: a Button with a Text child will never rebuild the Text widget since the parent "owns" the reference (not the Button!) and the engine would have seen it before.

The only way I can imagine this working is your build function making a call like ctx.stowore_widget_pls(|| Button { }) where the engine would call the function only once and re-use the resulting widget in perpetuity. Instead of deleting the elements from the tree outright, it would instead unmount the element (including all descendants, of course) and put it into a map so it can pull them back into the tree when it's used again.

That said, agui is not currently in a place where any real benefit would be noticeable or properly benchmark-able to go about implementing it right now. Developer ergonomics are also incredibly important and I'm unsure if adding such syntax sugar to the build! macro would turn out well.

// This:
build! {
    const Button {
        child: Text::new("zotz")
    }
}

// Becomes this:
ctx.stowore_widget_pls(|| {
    Button {
        child: Text::new("zotz")
    }
})

It's unclear on if it's worth the re-use of an already existing keyword and the very likely terrible error messages this would give out when you attempt to use something that's not properly const-able (in the widget sense, not rust sense) in your tree. It would likely complain about reference lifetimes since you're using a var in the closure that doesn't outlive it. It would also be possible to break it by writing this out yourself and adding move to the closure, which would break the guarantees of "this will absolutely never change throughout the life of the program."

Anyways, this is definitely something I have in the back of my head to look into, it's just not the highest priority item at the moment. There's absolutely a path to adding it even after a full release (whatever that looks like) since it's essentially just an implementation detail.

Edit: actually, thinking about it a tad more, if the closure was instead an fn instead of an FnOnce() it wouldn't allow move which would resolve that issue, so ignore that bit

[Stumblinbear]

So I spent the last few days thinking about this and actually figured out a way to do it that I don't hate! Anyways, it's implemented and functional already, haha

Currently it requires const to be included, but I'm thinking up some devious ways to make it automatic via the build! macro, since it should be able to detect if any variables were used, which is pretty much the only thing that would make a widget non-const-capable

[pmjobin]

Wow! That was quick!

I was about to suggest that perhaps the build macro could take care of caching the widget automatically when it encounters a const token but if it can infer widget const'ness without requiring the keyword, that's even better!

[Stumblinbear]

Yeah I got side-tracked on it because it was interesting and it ended up being much more straightforward than I thought before your question

It essentially just casts it to a fn() -> Widget which satisfies all of the constraints necessary to make it work. The only caveat being that it will be created once per thread, since it stores these in a thread_local! for performance reasons. Since fn() is both hashable and equality-checkable, it works perfectly as the hey to the Map storing the widget reference

[pmjobin]

I need to re-implement mouse events/gestures, focusing, and keyboard event handling. All of these relied on inherited widgets being completed so I can get them into the tree without hacks, and inherited widgets took me a good long time to figure out a way I was happy with implementing them.

Just out of curiosity, why does Agui use inherited widgets for input events? When I look at the Flutter documentation, it seems like all input-related widgets (like Listener, MouseRegion, Semantics, etc.) ultimately boil down to SingleChildRenderObjectWidget. This approach makes sense since render object widgets are the only ones that have knowledge about their screen dimensions (for hit testing). I admit I haven't delved deep into Flutter's source code but I'm guessing that when the PlatformDispatcher fires an event, it likely traverses the render object tree (or focus node tree for keyboard events) to determine which widget shall receive the event so I was wondering what is the role of inherited widgets in this process. Thanks.

[Stumblinbear]

I'll admit I'm not fully certain about if I'll end up using inherited widgets for these, but I'd like to explore the possibility so I can pick the best possible implementation

The main reason is that I'm looking to limit the amount of global state and reduce the possibility of desync issues that can occur. The more that can be handled in-tree the better. I actually just yesterday started refactoring some systems to use a plugin system, and winit/vello ended up being better suited to a hybrid of that and in-tree inherited widgets. If gestures are implemented as a plugin, it'll likely need to monitor the tree to tell if detectors have been removed (or detectors have to remove themselves) rather than them potentially being cleaned up automatically due to how inherited widgets naturally function.

Flutter's system works (very approximately) like: the platform dispatcher fires the event and the mouse handler picks up on this and does a hitTest, then fires the event on the widgets in order from most-specific to least-specific until it's handled. Keyboard events work with the focus system to determine where events are fired.

I'm not certain if I'm going to do this the exact same way, though it'll probably look quite a bit like it in the end. I just want to have the opportunity to explore different methods