Lokui: GUI framework experiment #5

Speykious · 2023-04-19T12:46:01Z

This is my own GUI framework experiment.

The goal is to create an architecture out of mostly my own intuition, and see if I can reason my way through an API that makes sense.
Currently, in practice, the framework turned out to have somewhat of a retained-mode object-oriented design, but with a way clearer separation between the state and the widget tree, so probably way less opportunity to turn the GUI into a monstrous unmaintainable spaghetti.

Explanations

Widget tree

The widget tree is organized as a strict ownership hierarchy, so widgets cannot directly use their parents. I believe it should be possible to make any kind of interface without resorting to this kind of cyclic reference.

It persists between frames, which means that the framework is not declarative. This could potentially cause problems later down the road, as the widget tree would need to be kept manually in sync with the state in case we need to dynamically add new widgets to the tree at runtime - which is a quite common occurrence, for example a Todo List demo, or a scroll view loading more messages as we scroll up. Such a thing remains to be tested however, and it is probably manageable despite the issue.

State

State is wrapped around either a Lazy, which is a newtype for Rc<RefCell<T>>. Since the primary goal of any kind of state is to be used and manipulated from multiple parts of the tree, it basically boils down to needing shared ownership and interior mutability. So this state management strategy is the first thing I thought of, and it turned out pretty well so far.

Components

The most important component so far is Pane. It can contain other components and lay them out in different ways. Currently it can stack them on top of each other or next to each other with a flex layout, but I plan to implement a grid layout at some point too.

The other components so far, Button and Text, are just there for testing purposes. Later on, I plan to inspire myself of Flutter and Frui, to make components as small as possible to have maximum customizability. For example, a widget that reacts on a click would be or contain a Clickable widget, and adding some padding to a widget means wrapping it inside a Padded widget. This won't necessarily mean that how you build the tree itself will look extremely indented, as once we have wrappers, we just need to augment widgets with additional methods like .on_click(...) and .padded(...) in a Builder pattern way.

Animations

TODO

Progress

Here are tasks I set myself to do with this framework:

Counter is now fully functional! :D

Taking lokinit's SkiaContext was stupid since we only need the canvas anyway. :)

Useless, until the flex layout changes directions and the buttons stay centered, probably as intended

A tuple turns out to be more convenient, I think.

This small pattern was repeated several times. Additionally, `default_solve_layout` is now out of the `Widget` trait to prevent it from being overridden.

AshesOfEther · 2023-04-20T11:54:26Z

Would it be okay for me to go through this and leave a few comments? I know this isn't finished so I just wanna be sure

Speykious · 2023-04-20T11:56:20Z

Go ahead, would really appreciate it! I've had some itches sometimes when I look at my code so if you have any suggestions, issues or questions in general, do ask. :D

AshesOfEther

Overall, I think the ergonomics of the API could be improved substantially. It is also not clear to me how conditional UI would work, or how repeated UI like a for loop would.

I'm also concerned about the usage of RefCell making it easy to mutably borrow a thing in a child widget, and then trigger a panic when the parent widget tries to borrow it during the child's borrow, or vice versa. This loses the benefit of Rust's compile-time borrow checker.

I might come back with more later, but this is what I got right now.

lokui/examples/counter.rs

AshesOfEther · 2023-04-20T12:40:35Z

lokui/src/layout/mod.rs

+pub enum DimScalar {
+	/// The widget fills its parent on that dimension.
+	#[default]
+	Fill,
+	/// The widget hugs its internal content on that dimension.
+	Hug,
+	/// The dimension is fixed by that amount of pixels.
+	Fixed(f32),
+}


Something akin to the flex property in CSS would be a huge increase in flexibility, as it allows children to specify how they grow and shrink in relation to each other to fill out a parent. This might be done as an extension of the Fill variant, which is equivalent to flex: auto in CSS, assuming this enum works like in Figma.

The enum is indeed directly taken from how Figma works, since that's where I had the best experience. Though I do realize there's way more potential for flexibility.

If you just mean an extension of the Fill variant, then I assume you mean for it to provide some kind of number to indicate the magnitude of how much it takes? Say, if we have 2 fills, Fill(2) and Fill(5), the former takes 2/7 and the second takes 5/7?

That would be quite a good extension and easy to implement. Are you thinking of more than this?

That would be the gist of it, yeah. Extending with something similar to CSS Grid later down the line, possibly making flex a subset of it, might be interesting. That's a later down the line idea though. This is a good start.

AshesOfEther · 2023-04-20T15:22:22Z

lokui/examples/counter.rs

+				.child(
+					pane()
+						.with_layout(
+							Layout::new()
+								.with_dimension(DimScalar::Fill, DimScalar::Fixed(50.))
+								.with_origin(Anchor::CENTER)
+								.with_anchor(Anchor::CENTER),
+						)
+						.child(text(value, font.clone())),
+				)
+				.child(
+					button(text("+1", font.clone()))
+						.with_layout(
+							Layout::new()
+								.with_dimension(DimScalar::Fixed(80.), DimScalar::Fixed(50.))
+								.with_origin(Anchor::CENTER)
+								.with_anchor(Anchor::CENTER),
+						)
+						.on_click(increment),
+				)
+				.child(
+					button(text("-1", font))
+						.with_layout(
+							Layout::new()
+								.with_dimension(DimScalar::Fixed(80.), DimScalar::Fixed(50.))
+								.with_origin(Anchor::CENTER)
+								.with_anchor(Anchor::CENTER),
+						)
+						.on_click(decrement),
+				),


A way to avoid writing almost the same thing three separate times would be nice.

Lol I didn't bother not repeating. xD
It's also not exactly the same thing. One is a text inside a pane, one is a +1 button, the other is a -1 button. The thing that could avoid some repetition here at best would be the button layouts, because they are the exact same... Which would make it slightly better since the with_layout bit takes the most space I guess :v

Of course, layout is what I meant to be referring to.

Speykious · 2023-04-20T16:33:13Z

I'm also concerned about the usage of RefCell making it easy to mutably borrow a thing in a child widget, and then trigger a panic when the parent widget tries to borrow it during the child's borrow, or vice versa.

This shouldn't happen. Components should store a Lazy value directly instead of a Ref<T> coming from a .get() call.
I made it so that it's intuitively what you have to do to manage shared mutable state: you .get(), use it and then the reference is dropped immediately; or you .set() and then you're already done borrowing. Since all of this happens in a single thread, there should be no mishaps as long as it's used that way.

Speykious · 2023-04-20T16:40:07Z

It is also not clear to me how conditional UI would work, or how repeated UI like a for loop would.

I don't have the answer to that yet! That's actually why I have a Todo List check, doing this example will concreticize at least one of these problems. Conditional UI should follow from there.

AshesOfEther · 2023-04-20T16:57:44Z

This shouldn't happen. Components should store a Lazy value directly instead of a Ref<T> coming from a .get() call. I made it so that it's intuitively what you have to do to manage shared mutable state: you .get(), use it and then the reference is dropped immediately; or you .set() and then you're already done borrowing. Since all of this happens in a single thread, there should be no mishaps as long as it's used that way.

Ahh, I see. Thanks for the clarification!

This solves the problem of not being able to add children after wrapping a pane with another component.

It wasn't really useful

Speykious added 29 commits April 16, 2023 01:09

I think I'm on to something there

468dc30

I got one button inside a panel with paddings 👀

6054eef

Got events to work with the whole system too

cb469f6

Turn playground into counter example

3a73fb4

Do not print while drawing

432a955

Stop printing while solving layout

acd189a

Add debug function to Widget trait

502494e

Simplify Anchor

6ebb16a

flex

38d06ca

Remove other useless prints

ed737bb

Get anchor-origin system right

e9dc989

Consistency in placement of constructor functions

b88dd1e

Implement text rendering

25fce4f

Counter is now fully functional! :D

Implement Display for Lazy<T>

ad39404

Implement basics of flex layout

bd6c2b9

Add a few comments

29e6b54

Add debug for Text component

4bd9b0e

Make Widget::draw take a Skia canvas

46d59e4

Taking lokinit's SkiaContext was stupid since we only need the canvas anyway. :)

small format and clean

008451f

That wasn't needed

8726f8b

Make lokinit a dev dependency

73d659e

Put buttons on true center

f5a05dc

Useless, until the flex layout changes directions and the buttons stay centered, probably as intended

FlexLayout's align property has no effect

a1350ff

Remove PaneChild struct

d1174ba

A tuple turns out to be more convenient, I think.

Put flex layout solving into a single function

fee22f3

Add flex layout gap logic

045e040

refactor: functions to solve width and height

cc6e3b6

This small pattern was repeated several times. Additionally, `default_solve_layout` is now out of the `Widget` trait to prevent it from being overridden.

fix: cargo fmt

e8fa294

Handle hover events

6b34435

AshesOfEther reviewed Apr 20, 2023

View reviewed changes

Speykious added 20 commits April 21, 2023 19:42

Basics of animation system

547580c

Woops, didn't mean to change that

241aad8

Add WithBackground widget wrapper

1b36d4f

Add a WidgetContainer trait

7edfde9

This solves the problem of not being able to add children after wrapping a pane with another component.

Remove Laz

a927665

It wasn't really useful

Remove unused imports

289f752

Use get_mut() in example

6393c0d

Remove now useless set method for Lazy

1aed813

Make padding a wrapper

27f1aed

Slightly decrease verbosity w/ color in RectState

b2a4f5f

Rename FlexLayout to Flex

58f247d

Introduce a prelude module for ease of imports

363a9f0

Actually making padding a wrapper was a bad idea

9a7247a

Add WithOnCLick and WithOnEvent wrappers

8fcefa3

Make on_click callback return a boolean

cf11755

Add argb_hex method to Color

3845d90

Make counter example look slightly better

6b6cb6e

Replace old lokinit code with winit for now

3fdf34b

Ah yes, the up is made out of down

bbd32b9

Fix Skia drop order bug and simplify example

6508348

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Lokui: GUI framework experiment #5

Lokui: GUI framework experiment #5

Speykious commented Apr 19, 2023 •

edited

Loading

AshesOfEther commented Apr 20, 2023

Speykious commented Apr 20, 2023

AshesOfEther left a comment

AshesOfEther Apr 20, 2023

Speykious Apr 20, 2023

AshesOfEther Apr 20, 2023

AshesOfEther Apr 20, 2023

Speykious Apr 20, 2023

AshesOfEther Apr 20, 2023

Speykious Apr 20, 2023

Speykious commented Apr 20, 2023

Speykious commented Apr 20, 2023

AshesOfEther commented Apr 20, 2023

Lokui: GUI framework experiment #5

Are you sure you want to change the base?

Lokui: GUI framework experiment #5

Conversation

Speykious commented Apr 19, 2023 • edited Loading

Explanations

Widget tree

State

Components

Animations

Progress

AshesOfEther commented Apr 20, 2023

Speykious commented Apr 20, 2023

AshesOfEther left a comment

Choose a reason for hiding this comment

AshesOfEther Apr 20, 2023

Choose a reason for hiding this comment

Speykious Apr 20, 2023

Choose a reason for hiding this comment

AshesOfEther Apr 20, 2023

Choose a reason for hiding this comment

AshesOfEther Apr 20, 2023

Choose a reason for hiding this comment

Speykious Apr 20, 2023

Choose a reason for hiding this comment

AshesOfEther Apr 20, 2023

Choose a reason for hiding this comment

Speykious Apr 20, 2023

Choose a reason for hiding this comment

Speykious commented Apr 20, 2023

Speykious commented Apr 20, 2023

AshesOfEther commented Apr 20, 2023

Speykious commented Apr 19, 2023 •

edited

Loading