Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

About ListItem object #27

Open
fperillo opened this issue Oct 10, 2017 · 1 comment
Open

About ListItem object #27

fperillo opened this issue Oct 10, 2017 · 1 comment

Comments

@fperillo
Copy link
Contributor

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).

@laserpants
Copy link
Owner

laserpants commented Oct 11, 2017

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants