Adaptive Card collection

[marco-piccolino]

it would be very useful to have a component that takes care of displaying card collections based on the available screen real estate, device type and specified minimum and maximum card widths.

It could be a subclass of GridView, and adjust cellWidth (and thus column numbers) based on the card's specified min and max width, reducing it to one column on mobile.

I cannot find much in the Material specs about this matter. I'm reporting this conversation I had on the topic about how this is dealt with for the Onefootball app on Android:

https://twitter.com/marco_piccolino/status/593342379630952448

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Gennon]

I GridView could work, but I think maybe a Flow + Repeater + Flickable could be better. http://ruedigergad.com/2012/11/24/qml-flowlistview/

However then it would need some rules so that it can't have open spaces. So basically a card is default small but on some occasions it could be large. But you can't have 1 small and then 1 large, you have to have 2 small and then 1 large. So a little sorting algorithm should do the trick.

http://www.google.com/design/spec/components/cards.html

[glaucopgomes]

That's a great idea, but I think it should not be limited to only contain cards.
I can do something with photographs, dvd/bd covers, cd covers, etc.

[marco-piccolino]

@glaucopgomes Cards are a very flexible component and can display all those content types that you are mentioning. For a more restricted layout there are Material grids and grid tiles.

The collection anyways should support the delegate property, so that the actual delegate component could be whatever you need it to be, but generally it should really subclass the Card component so that the outcome is predictable.

@Gennon good pointer! Perhaps the component might initially support only equal-size cards and later allow for optimal tiling of different card sizes

[marco-piccolino]

@ibeliever any thoughts on this?

[iBelieve]

I wrote a ColumnFlow component awhile ago that is like a flow layout but is vertical (so the delegate items can be different heights): https://github.com/iBeliever/ubuntu-ui-extras/blob/master/ColumnFlow.qml

The Ubuntu Touch Music app developers wrote their own version of this which is probably better: http://bazaar.launchpad.net/~music-app-dev/music-app/remix/view/head:/common/ColumnFlow.qml

If I or one of you guys can test that component, I can reach out to the author and see if he'll let us license it under the LGPLv2.1+ instead of the LGPLv3.

[marco-piccolino]

@ibeliever awesome. I cannot commit to testing immediately as I have a few pending project deadlines. If nobody is taking this up I'll come back to it in a couple of weeks.

[glaucopgomes]

@marco-piccolino the delegate solve any requirement that anyone can have.

[Gennon]

At the three images shown here: http://www.google.com/design/spec/components/cards.html#cards-content

There are basically just two different widths, but several variations in height. Of course it could be different on Desktop vs Tablet vs Phone. For instance a Desktop could support 2 large cards on one row, and 4 small ones, while the phone only supports at most 1 large card on one row.

[marco-piccolino]

@ibeliever I made a very quick test with the ubuntu music component. It does work quite well. Haven't tried yours tho. To make it work I just changed the units from gu to dp and increased buffer height.

https://github.com/marco-piccolino/columnflow

[marco-piccolino]

@ibeliever here is some feedback I got from Andrew Hayzen (the columnFlow author) about the component. Please get in touch with him directly re. licensing if you think that the component is a good starting point for further customisation in Material rather than the one you put together, as given my limited knowledge of performance issues in Qt I am not able to judge it.

"Please do note that although this component was designed to be for generic use, it was also designed for the Music-app's limitations/requirements. Therefore currently it does not remove generated 'cards'/delegates as the thumbnailer takes ages so once the delegate has been created we don't remove it when it goes out of view. (It did used to do this but until the thumbnailer improves we have to leave this limitation in) This does mean that the memory isn't released for those components, so if you had a huge list and scrolled down it would keep increasing in usage.

On the upside, the delegates are only created when need and its done in a background thread :) We haven't noticed any super high memory usages so its probably not something to worry about greatly, just something to be aware of for now. Also IIRC the out of view cards are set to visible: false so they aren't rendered.

Anyway great to hear other people making use of the component, please message me if you have any further questions/issues."