Support list paging operations about brick HOT 17 CLOSED

Sounds great. I imagine the *Lensed version will be optional - avoiding too much lens magic helps keep brick easy to learn.

from brick.

Absolutely! The lens version would be for convenience, but you could always write the code yourself; it would just be a little more clunky. My plan in general is to always keep the lens-y bits of the brick API optional.

from brick.

FWIW, this work is underway on the feature/eventm-change branch.

from brick.

Okay: the feature/eventm-change branch is ready to be tried. Aside from running event handlers in EventM, the other noteworthy API change here is that the item height that was previously passed to renderList is now passed to list. This is because the item height now has to be known in the event handler for List, so it has to be stored there.

from brick.

Page up/page down working, thank you!

Notes:

• I wonder how I would display a "last end of page position" indicator, always useful for the last partial page down
• Home/End key too ?
• Should shift-pgup/pgdown/home/end have the same effect horizontally, for wide content ?
• why did you remove Widget's IsString instance, that seemed quite useful

from brick.

• Displaying an end of page indicator is going to be tricky, but it can be done. You can only get at the viewport state for the list in an event handler using lookupViewport, and you'll have to do some math to divide the list's height offset by the list's item height to figure out where the viewport's height offset lines up with a list element. (If your item height is 1, you have it easy.) And you'd have to store the resulting value in your application state so your drawing routine can access it.
• Support for Home/End added in 717186e
• Wide content would need to be handled on a case-by-case basis. Lists are intended to be for vertically-scrolling content only, not horizontal, so if you want to be able to scroll in two dimensions then other approaches need to be considered. The key handling that you get when you use Lists is specific to Lists, not specific to vertically-scrollable things. Does that make sense?
• I'm conflicted about the IsString instance for Widget. I agree that it's really nice to have, but brick also provides a couple of other types with IsString instances and there is room for confusion since your program will have string literals that mean different things. I removed it for a different reason, which is that the type for Widget moved to Brick.Types but the function I need for the instance is in Brick.Widgets.Core, so I only have one choice: make an orphan instance. In general I don't mind orphan instances, but in this case it's bad because you have to import two modules just to get the instance, and that makes for a weird API. I'd like to reinstate the instance but not with things laid out the way they are now.

from brick.

Wonderful, Home/End are quite nice to have.

List are not for horizontal scrolling - ok. (I do have wide tabular content for which horizontal scrolling would be useful, but that's probably a whole new widget...)

from brick.

Yeah, I think it's definitely worth thinking of the List as a simple convenience rather than as a catch-all widget. It could be good to discuss what your needs are (I know nothing about your application). How wide is this tabular content you need to display?

from brick.

Multi-column balance reports tend to be wider than the screen when you want your report columns to be months, weeks or even days.

Ultimately I'd like to be able to pan around on a wider/taller-than-screen table like this, selecting individual cells and drilling in to see the relevant transactions.

from brick.

in that case, I recommend an approach like the one taken in the Visibility demo as a starting point, i.e., instead of using a List, use a visibility request as your cursor and place the whole multi-column drawing in a viewport.

from brick.

Noted, thanks.

Worth adding the unix-style SPACE/BACKSPACE keys as an alternative for PGUP/PGDOWN ?

from brick.

I'm not familiar with that convention; is that very common? (I would expect Space, at least, to have some other meaning.)

from brick.

Space bar for next page is common in unix programs with paging functionality like more/less/info, and eg in web browsers too (http://ux.stackexchange.com/questions/53110/why-does-the-space-bar-do-page-down-in-browsers). Backspace for page up is also used but less common/reliable than I thought. I guess I can always add it myself, so not a big deal.

from brick.

Okay. I have used it in pagers, but that's all; so I think it's best if we go with adding it on a case-by-case basis.

from brick.

@simonmichael - I don't want tickets to get stale and I have the impression that this one may be finished, at least for the time being. If you agree, can you close it?

from brick.

I don't have permission, but that sounds fine, thanks.

from brick.

Oh, whoops. I forgot that you didn't open this. Thanks!

from brick.