Grid widget

[daxpedda]

This relies on #187, but this reliance can easily be circumvented.

Currently table has no settings and shows no other visuals then it's content.
Any feedback would be appreciated.

[daxpedda]

Rebased.
The API definitely needs a discussion.

[hecrj]

As we discussed in the Zulip, a Table widget is tricky to get right. We should answer some of the questions we raised there first.

I think we are missing a clear use case here. The widget implementation seems to be laying out content smartly, but I think it's hard to predict exactly how. For instance, what happens if a cell is very wide?

Additionally, I think the current widget is more of a Grid widget than a Table widget, as it does not support headers nor display cell separators. This is fine! I think a Grid widget is a better way to start exploring this kind of layout.

Overall, I believe we should reduce a bit the scope of this, compromise functionality, and tackle a specific use case directly. For instance, maybe we could try to implement a Grid with a fixed column width (or number of columns) provided on creation. Users can push elements directly (like in a Column) and the Grid will automatically wrap elements smartly and keep track of each row height. I think this has a clearer scope with a more predictable behavior. We should also showcase this in a cool example.

Finally, do not worry about the iced_web version too much. We can tackle that in another PR in the future.

[daxpedda]

For instance, what happens if a cell is very wide?

Providing a max width for the whole grid would be a good start, what do you think?

For instance, maybe we could try to implement a Grid with a fixed column width (or number of columns) provided on creation. Users can push elements directly (like in a Column) and the Grid will automatically wrap elements smartly and keep track of each row height.

That sounds great! We can do it like HTML and provide the ability to put settings on the items themselves by simply adding push_with_settings or something similar later.

We should also showcase this in a cool example.

Gonna work on that when we finish the API.
Should I put it in tour or into a specific example? Or should I make a dedicated one?

Finally, do not worry about the iced_web version too much. We can tackle that in another PR in the future.

I don't mind, I'm using the web target more right now then the desktop one.

[hecrj]

We can do it like HTML and provide the ability to put settings on the items themselves by simply adding push_with_settings or something similar later.

Let's keep it simple for now!

Should I put it in tour or into a specific example? Or should I make a dedicated one?

I'd make a dedicated one. The tour is already complex enough. I will update it eventually to showcase all the new stuff.

[daxpedda]

I'd make a dedicated one.

On it.

[hecrj]

Looking very promising!

I believe this widget will be very useful. I've been missing something like this in some of my projects.

[ajax-crypto]

I have been following this project for quite some time now, just want to understand the rationale behind a grid widget vs. a grid layout. Shouldn't grid be a layout strategy rather than a widget? (I might be completely wrong here) I would expect table/tree (with multiple columns, lazy loading, pinning, etc.) to be widgets.
In future, I am looking forward to a tree widget, with the above mentioned features and a form of grid layout (desktop target). (Using Qt/C++ right now, planning to move to Rust).

[hecrj]

@ajax-crypto A widget is just a node in the view tree. They usually represent interactive and visual elements, but they can also be used to implement containers with different layouts (like Column and Row).

Flutter, for instance, has widgets like Padding, GridView, Column, Row...

[hecrj]

We are close, just a couple of details!

[hecrj]

Just took another look at this. Sorry for the late review!

Now that the layout code is much more readable, I think this is mergeable! However, It would be great to have a simple example showcasing both strategies (maybe with a toggle checkbox or something). Would you like to take a shot at it? Let me know.

I also noticed the Widget::on_event implementation was missing, so I have added it myself.

[daxpedda]

Sorry I was busy for some time now too.

About the example, would love to take a shot at it, but I would like you to tell me what kind of use case you had in mind for the grid widget.

[hecrj]

Sorry I was busy for some time now too.

Absolutely no worries. I am already very grateful you took the time to contribute!

About the example, would love to take a shot at it, but I would like you to tell me what kind of use case you had in mind for the grid widget.

The use case I had in mind is visualization of any dynamic list of items with small amounts of data. Image galleries, dashboards, and menus are the first real applications that come to mind.

I think examples should be interesting and showcase real use cases without being overly complicated, so something like an image gallery or a dashboard may be a bit too much...

Maybe we could build something like a github_explorer. An example that has a TextInput accepting a GitHub username which, once submitted, displays in a grid the user's top 10 repositories. Or maybe something similar but using crates.io? I am just brain-storming. Feel free to propose any other ideas!

Hope this clarifies a bit the use cases I had in mind.

[victorstewart]

just to pipe up from the peanut gallery, what I've love to see and use here is something akin to the beautiful collection views in iOS just without all the unnecessary junk.

So... a callback to generate a view element for a given index, recycle those views, callbacks when elements become visible, have the views be bounds aware so they can conduct animations at boundaries, feed an explicit layout map to the collection, allow items to be placed anywhere and of any size, the ability to tap on one and remove it from the tree and focus it forefront consuming the whole screen then put it back in its place...

I use such collections on iOS for all the core visual experiences in my app so I've hacked them extensively.

[daxpedda]

I don't belive I'm going to be able to contribute to Iced for a while 😞.
Everybody is free to reuse my code that I produced here.

[hecrj]

@daxpedda No need to close this! Also, no worries whatsoever. I will work on merging your work soon.

[Luni-4]

@daxpedda

Is this PR abandoned or it can be reopened? I'm using your widget in a project and it is really useful, thanks a lot for your work! It would be great if it could be merged upstream also 😃

[daxpedda]

I can't reopen it because I already deleted my repo and everything, sorry about that!
Personally I'm not gonna continue this anymore, anybody can feel free to copy the code from here and make a PR.

This is kinda annoying, but maybe this helps:
https://patch-diff.githubusercontent.com/raw/hecrj/iced/pull/189.patch
https://patch-diff.githubusercontent.com/raw/hecrj/iced/pull/189.diff

[Luni-4]

Oh, I'm sorry to hear that! I could try to open a new PR in the next days using your patch, rebased on the current master, since your changes have already been approved previously.