8000 Core layout widgets · Issue #1 · fruiframework/frui · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
This repository was archived by the owner on Feb 9, 2024. It is now read-only.

Core layout widgets #1

Open
8 of 22 tasks
toiglak opened this issue Sep 30, 2022 · 11 comments
Open
8 of 22 tasks

Core layout widgets #1

toiglak opened this issue Sep 30, 2022 · 11 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@toiglak
Copy link
Member
toiglak commented Sep 30, 2022

Following is a list of some of the more important core layout widgets that need to be implemented.
Their exact API is up for debate, since there may be better ways to adapt those to Rust.

Single-child layout widgets

Multi-child layout widgets

@toiglak toiglak added enhancement New feature or request help wanted Extra attention is needed labels Sep 30, 2022
@nicoburns
Copy link

You might want to consider adding more layout modes. Two Rust libraries for layout that already exist:

  • (Taffy)[https://github.com/DioxusLabs/taffy] which implements flexbox, and is planning to implement more layout algorithms such as CSS grid.
  • (Morphorm)[https://github.com/vizia/morphorm] a simplified but flexbox-like layout system.

@xanahopper
Copy link
Contributor

Interesting and nice framework! which is what I'm want (but with a little missing)
Maybe I can implements some of widgets.

The missing I mentioned is that:

  • Platform shell: Android and iOS
  • Multiple window support
  • Multi-thread render
    And maybe a fiber(React tech) like widget build/layout call, interrupt and resume mechanism.

But I'm very interesting with all these, we may have some discuss in future.

@xanahopper
Copy link
Contributor
xanahopper commented Oct 16, 2022

After some code reading, I found that this project highly depends on druid and piet.
The former is now just focused on desktops, the latter is just an abstract wrapper for desktop drawing systems.
But I noticed piet is working on some GPU-accelerated, aka piet-gpu, which is exactly what this project needs.
IMO, before piet-gpu's matures, we can do some top-level design to be compatible with both mechanisms.

And what do you think about the Xilem? It is similar to frui, and it may be implemented by druid.

btw, the implements of Widgets may be too verbose for me. but I can live with that for now.

@toiglak
Copy link
Member Author
toiglak commented Oct 17, 2022

After some code reading, I found that this project highly depends on druid and piet.
...
IMO, before piet-gpu's matures, we can do some top-level design to be compatible with both mechanisms.

I'm focused on making the high-level API as ergonomic as it is possible in Rust (it's my obsession at this point haha). While at it, the lower level API for interacting with drawing should still be high enough so that Frui could theoretically switch backends at any point in time without breaking user code (e.g. we should be able to switch from piet to wgpu if we ever needed to, but of course I am confident in piet).

Currently that's not possible as I took a lot of shortcuts in the current implementation (e.g.PaintContext from piet is passed to the user API as-is), but with time I want those exact implementation details to be abstracted.

what do you think about the Xilem? It is similar to frui, and it may be implemented by druid.

A few months ago, I subscribed to Raph Levien’s blog. Now, every time he posts, I am thrilled to see his ideas and work (I really like his style of writing). I think Xilem tries really hard to be as much zero-cost as possible while keeping the ui code ergonomic. I think Xilem does a great job on that front.

What I'm most excited about is that Xilem and Frui came to similar design decisions, even though those projects were developed separately and with slightly different goals in mind. Some of those are:

  • defining children list through tuple (it's ergonomic and avoids allocations) and
  • type erasing View into object-safe AnyView (I still have no idea how I hallucinated this pattern on my own in Frui 😆)

In the end, I just hope that Frui and Xilem can improve by learning from each other. I believe that working together towards one goal (bringing the Rust UI vision to life) from different perspectives can only accelerate that process.

btw, the implements of Widgets may be too verbose for me. but I can live with that for now.

Yeah it's a mess 😄. I am working on it right now.

@toiglak
Copy link
Member Author
toiglak commented Oct 17, 2022

You might want to consider adding more layout modes. Two Rust libraries for layout that already exist:

I will be rewriting the layout/drawing API soon. I'll make sure to give those layout modes a try while at it.

@xanahopper
Copy link
Contributor
xanahopper commented Oct 17, 2022

You might want to consider adding more layout modes. Two Rust libraries for layout that already exist:

I will be rewriting the layout/drawing API soon. I'll make sure to give those layout modes a try while at it.

Maybe I can implement other Widgets after your new layout/drawing API's rewriting?

@rathod-sahaab
Copy link

I would also like to contribute to the development, my rust knowledge is only theoretical 😅

@toiglak
Copy link
Member Author
toiglak commented Oct 17, 2022

Maybe I can implement other Widgets after your new layout/drawing API's rewriting?

I will highly appreciate help with this!

I would also like to contribute to the development, my rust knowledge is only theoretical

I will setup Discord/Zulip later so we can talk more freely.

@xanahopper
Copy link
Contributor

I think we need Discord, many things need to be discussed.

  • the form how widgets are written
  • the best way to allocate, own and borrow widgets and their children
  • default values

@toiglak
Copy link
Member Author
toiglak commented Oct 21, 2022

Ok, Discord server is up! It's in pretty rough shape, but it will do for now! (also discussion tab is now active on github)

Discord

@xanahopper
Copy link
Contributor

#4 has just fired, Stack is implemented.

toiglak pushed a commit that referenced this issue Oct 25, 2022
toiglak pushed a commit that referenced this issue Feb 9, 2024
toiglak pushed a commit that referenced this issue Feb 9, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants
0