Pager Feature #9

New Issue

cmccabe · 2019-11-21T13:21:15Z

cmccabe commented

2019-11-21 13:21:15 +00:00

If a menu needs to display 500 links, let the user page through them at, say, 20 links per page.

cmccabe added the

future release

label 2019-11-21 13:21:15 +00:00

asdf commented

2020-06-29 03:51:53 +00:00

I have been thinking about this one, working like:

We limit the number of items shown to only those that will fit within the console window.
Any items overflowing the limit end up on the next page.
Controls are added to allow navigation between pages.

An example would be that upon starting the application, the first 5 categories are shown because we calculate that only those 5 will fit. A command to view the next page can be used to show the next 5 categories.

Should items be numbered from 1 onwards each page? So each page shows 5 links, numbered 1 to 5. Or should the numbering continue on?

I have been thinking about this one, working like: 1. We limit the number of items shown to only those that will fit within the console window. 2. Any items overflowing the limit end up on the next page. 3. Controls are added to allow navigation between pages. An example would be that upon starting the application, the first 5 categories are shown because we calculate that only those 5 will fit. A command to view the next page can be used to show the next 5 categories. Should items be numbered from 1 onwards each page? So each page shows 5 links, numbered 1 to 5. Or should the numbering continue on?

cmccabe commented

2020-06-30 10:22:46 +00:00

I think 1-5, 6-10, ..., is best because the user may want to back up, and the non-repeating numbers would be an indicator of how deep (far back) they've gone.

The one challenge I would see to the non-repeating numbers is if the application data were refreshed in mid-use, because that could throw off the sequence. Of course this is only a problem if there were many concurrent users of linkulator, which is not a problem now.

I think 1-5, 6-10, ..., is best because the user may want to back up, and the non-repeating numbers would be an indicator of how deep (far back) they've gone. The one challenge I would see to the non-repeating numbers is if the application data were refreshed in mid-use, because that could throw off the sequence. Of course this is only a problem if there were many concurrent users of linkulator, which is not a problem now.

sloum commented

2020-06-30 14:24:37 +00:00

I'm not sure that would be a problem @cmccabe . Since an individual user using linkulator works off of an in memory version of the data. Realtime data would not be seen by them from the time they start the program.

cmccabe commented

2020-07-01 14:42:35 +00:00

Good point @sloum, I guess I was misremembering that the data reloaded when the user added a link. But actually, even if that were so, they would not be in the pager feature at that time, so it wouldn't matter.

asdf commented

2020-07-02 02:59:21 +00:00

Any new items - categories, links or replies - will be displayed in the client as soon as they are made. This is only for items you have added though, it doesn't currently check for things that other people might have added.

Having 1-5, then 5-10 and so on, does help with understanding page progression. On the down side, it means by page 3, choosing a link means pressing one more key.

We can try either way, probably starting with whichever is easiest.

Any new items - categories, links or replies - will be displayed in the client as soon as they are made. This is only for items you have added though, it doesn't currently check for things that other people might have added. Having 1-5, then 5-10 and so on, does help with understanding page progression. On the down side, it means by page 3, choosing a link means pressing one more key. We can try either way, probably starting with whichever is easiest.

asdf self-assigned this 2021-07-28 23:52:49 +00:00

asdf commented

2021-08-03 08:43:54 +00:00

I have a basic model of this in the pager branch. Menu screens will only print what currently fits in the terminal window, splitting contents to pages.

Navigation can be done between next and previous pages, as well as forward and back in the menu heirarchy (categories -> category details -> thread_details). I don't know that this works, and have found two axes of control a bit confusing.

This new implementation seems complicated so I'm looking to simplify it as much as possible.

edit: i don't think this is the right approach. it's a lot of page control mixed in with menu logic, mostly to avoid having to do lower-level terminal control. the actual experience seems a bit unweildy and I feel like scrolling through a list rather than changing pages would be more intuitive. Plus page changes use an escape code to clear the screen which messes with the user's terminal buffer.

going to think about #16 instead. seeing how rendering works in bombadillo makes me think curses or manual terminal control would be a much less complicated approach.

I have a basic model of this in the pager branch. Menu screens will only print what currently fits in the terminal window, splitting contents to pages. Navigation can be done between *n*ext and *p*revious pages, as well as *f*orward and *b*ack in the menu heirarchy (categories -> category details -> thread_details). I don't know that this works, and have found two axes of control a bit confusing. This new implementation seems complicated so I'm looking to simplify it as much as possible. edit: i don't think this is the right approach. it's a lot of page control mixed in with menu logic, mostly to avoid having to do lower-level terminal control. the actual experience seems a bit unweildy and I feel like scrolling through a list rather than changing pages would be more intuitive. Plus page changes use an escape code to clear the screen which messes with the user's terminal buffer. going to think about #16 instead. seeing how rendering works in bombadillo makes me think curses or manual terminal control would be a much less complicated approach.

asdf commented

2021-08-08 06:26:01 +00:00

The pager branch now uses curses to display content. You can use it to view content only at the moment.

The controls are very similar to bombadillo:

j/k or up/down arrow to scroll a page
numbers keys to select an item on the screen
b to go back
q to quit
: or space to open a prompt, where you can enter numbers to navigate or commands like q, quit, exit or whatever.

Still a work in progress, a bit of a mess. It uses a big nested class thing for the menu so you end up with massive variable names. Need to think of nicer ways to handle this. Also this is my first time with curses, so am not entirely sure i have it right. Screen output is also similar to bombadillo as I wasn't sure how the curses scrolling was meant to work entirely.

The pager branch now uses curses to display content. You can use it to view content only at the moment. The controls are very similar to bombadillo: - `j`/`k` or up/down arrow to scroll a page - numbers keys to select an item on the screen - `b` to go back - `q` to quit - `:` or space to open a prompt, where you can enter numbers to navigate or commands like q, quit, exit or whatever. Still a work in progress, a bit of a mess. It uses a big nested class thing for the menu so you end up with massive variable names. Need to think of nicer ways to handle this. Also this is my first time with curses, so am not entirely sure i have it right. Screen output is also similar to bombadillo as I wasn't sure how the curses scrolling was meant to work entirely.

asdf added

enhancement

this release

and removed

future release

labels 2021-08-19 08:05:02 +00:00

asdf referenced this issue

2021-08-19 08:16:10 +00:00

Consider curses for Display Formatting #16

asdf commented

2021-08-22 10:25:34 +00:00

Still working on this one, it's getting closer to being feature complete. Will be asking for some initial feedback.