You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was about to complete the 3 variants of the ListItem object: 1, 2 and 3 lines are the basic variants, icons and avatars are ancillary.
I started with the idea to have 3 QString and adapt height and geometry based on the number of text lines set.
Then I played with the idea of a AbstractLineItem with base methods/data from which derive Divider and ListItem1, ListItem2 and ListItem3.
I then played with the idea of switching from a completely "ownerdrawn" widget, to a widget made with a layout and composed by different widgets. It would be easier to later implement advanced and interactive features like menus, expanders, etc. What do you think would be better? With ownerdrawn we have complete control on how to paint the widget, with layout we should double check everything...
Comparing material-ui and material.io I found discrepancies in what it is possible to implement. One is the possibility to have left and right icons: the specs don't have them listed, no measures... there is only one picture (look at Ali Connors picture, with left telephone icon and right quote icon).
The text was updated successfully, but these errors were encountered:
I then played with the idea of switching from a completely "ownerdrawn" widget, to a widget made with a layout and composed by different widgets. It would be easier to later implement advanced and interactive features like menus, expanders, etc. What do you think would be better? With ownerdrawn we have complete control on how to paint the widget, with layout we should double check everything...
Without having looked at the code or anything, I think the layout-based approach sounds preferable. If you have some code, and don't want mess around with git too much, you can just send it to my email as a tarball or something.
Comparing material-ui and material.io I found discrepancies in what it is possible to implement.
I am not sure I understand, but I have been looking at the App Bar component recently, and maybe what I am struggling with there is something similar. I don't want to bloat the API with a bunch of settings and configuration options, but the approach I think I'll take is to make the component really basic, and then add different standard layouts that a user can use as, sort-of, templates to achieve the finished App Bar with menus and other stuff. I think I completely misunderstood your question however, 😆. Sorry!
I was about to complete the 3 variants of the ListItem object: 1, 2 and 3 lines are the basic variants, icons and avatars are ancillary.
I started with the idea to have 3 QString and adapt height and geometry based on the number of text lines set.
Then I played with the idea of a AbstractLineItem with base methods/data from which derive Divider and ListItem1, ListItem2 and ListItem3.
I then played with the idea of switching from a completely "ownerdrawn" widget, to a widget made with a layout and composed by different widgets. It would be easier to later implement advanced and interactive features like menus, expanders, etc. What do you think would be better? With ownerdrawn we have complete control on how to paint the widget, with layout we should double check everything...
Comparing material-ui and material.io I found discrepancies in what it is possible to implement. One is the possibility to have left and right icons: the specs don't have them listed, no measures... there is only one picture (look at Ali Connors picture, with left telephone icon and right quote icon).
The text was updated successfully, but these errors were encountered: