#52 google like paging

George Mandella

----- Message Text -----

check out maximum_pages and maximum_page_buttons

after maximum_pages have been reached you can still next through it, but
it doesn't iterate the paging.

FAQ 4.19

It would be nice if page numbering could function as follows:

when maximum_page_buttons is greater than maximum_pages and a user clicks
'next page' when they're on the last page of maximum_page_buttons that the
paging would adjust accordingly. For example:


A user is on page 20 and hits 'next'

The paging now displays pages 2-21 instead of 1-20. If they hit next
again, the paging says 3-22 and so on. Thus, maximum_page_buttons is
defined as a range within maximum_pages. In other words, if it could
function similarly to google which allows for usable traversing of massive
result sets. I understand that this might complicate things on the
configuration parameters that affect display (like page_number_text and
no_page_number_text) but that seems like a tradeoff worth exploring.

Personally, I'd be happy with a configuration for page_number_text as follows:
page_number_text: txt

to have txt-based rendering of page numbers

page_number_text: img

to dictate some automatically generated img src based on a naming convention rather than the
hard-coded configuration that currently exists.



  • Logged In: YES

    If you leave page_number_text or no_page_number_text
    as an empty string, as it is by default in its compiled-in
    settings (as opposed to the sample htdig.conf), then these
    attributes will default to text based rendering of page numbers.
    They also render page numbers as text for page numbers
    that go beyond the size of list that you set these to.
    E.g., if you give these attributes a list of 10 buttons, but you
    set maximum_page_buttons to 20, then buttons 11 to 20
    are rendered in text.

    I've thought about what it would take to make htsearch give
    a "floating" range of page buttons when maximum_pages
    is larger than maximum_page_buttons, but this would only
    work well if page_number_text and no_page_number_text
    were empty - otherwise you'd run out of graphic items in
    these lists, unless you came up with a scheme for automatically
    generating the img tags based on page number (e.g. using
    a %d in a single item in page_number_text).

    In any case, this would need to be optional, as I'm not convinced
    everyone would want this. So, it's a good idea, but to make it
    really work well would take more than a trivial effort, which was
    why I never acted on it when I first thought of it.

    • assigned_to: nobody --> grdetil
    • labels: 105979 --> 105977
    • priority: 5 --> 4
    • status: open --> open-later
    • labels: 105977 -->
    • milestone: 102988 -->
    • assigned_to: grdetil --> nobody
  • Logged In: YES

    Classified this as a feature-request, not a bug.