Question: Variable Height List Widget

[mpickering]

Do you know if anyone has implemented a widget which works like List but allows for each item to have a different (undetermined) height?

My use case is that I need to display a list of comments which have different lengths. I want to use something List so that each comment can be selected and the whole list can be scrolled for long threads but having to limit the list to a set size is restrictive.

[jtdaugherty]

I don't know of any implementation of this in the wild. I've had to deal with this situation myself in matterhorn, but it's a challenge to do.

A List can't support this because the height of each item needs to be known in advance in order to efficiently render the list. A List with items J rows high, rendered in an area N rows high, renders at most 2 * K elements, where K = N / J. It then translates the rendering so that it works in a viewport. This trick won't work if J isn't the same for all of the items.

One approach that might work, depending on the number of items, is to cache all of the item renderings in the rendering cache. Then, when the item selection changes (which presumably changes its rendering), invalidate the cache entries for the previously-selected and newly-selected items. Render them all in a vBox inside a viewport and tag the selected item with visible. Then viewport will take care of scrolling state management. That might work, but it can still suffer from performance issues if there are enough items and it can also be a non-starter if your item renderings need to change often.

Another approach that might work -- but that I haven't tried myself -- is to just not use viewport at all, and to instead track your viewport state in your own event handler and application state. (This would probably entail using extent tracking to obtain information about your UI layout in the handler.) The reason this approach may be necessary is because you can then have logic in your drawing code that draws the right contents depending on the event handler's changes to the viewport state. The viewport function is really intended to be used with render-cached content so that it's cheap to render (and then translate) the contents. For what it's worth, I see this as probably the most common design challenge in Brick programs. If you go with this approach and can make it work, I'd love to hear about it!

[mpickering]

@romanofski Have you tried to implement anything like this in purebred?

@jtdaugherty Thanks. Your first idea sounds promising, it does sounds fiddly to get the performance characteristics right though which is why I was hoping someone else had already done it!

[romanofski]

@mpickering we haven't had the need for it unfortunately. We use the list widget and display subject and static mail information which means there is no need for a dynamic height. Having said that, I do want to implement a similar discussion view like sup had implemented which follows what Gmail shows. That is too far down the track and I guess we think about widgets when we have caught up with the rest of the functionality. For that we are probably looking at a new widget anyway, because it would have to show a tree view of mails (within a thread).

[jtdaugherty]

@mpickering do you have what you need to move forward? I'd like to close this unless there's something more I can help with.

[mpickering]

I don't have plans at the moment to implement this so we can close this issue and anyone wondering about the same thing can find our collective wisdom here.

[jtdaugherty]

Okay. Thank you!