Kord-Extensions/kord-extensions

Paginator that supports arbitrary messages (plain text, multiple embeds, etc.)

Closed this issue · 1 comments

beer-psi commented

Summary

Add the ability for paginators to support arbitrary content in pages.

Current Behaviour

Paginators (down to the BasePaginator) only support single-embed pages, because each Page can only take a single embed.

Preferred Behaviour

Paginators should be able to support more content. Originally in the Discord server I only talked about supporting multiple embeds, but I believe it can be useful to support other types of content (if possible).

Suggestions

A Page can take a MessageCreateBuilder instead of a simple EmbedBuilder, which would allow richer pages.

For displaying pagination information, there can be a toggle to switch between 2 different styles:

  1. In the footer of the last embed (if there is an embed, else fall back to style 2)
  2. Create a final embed with pagination information in its description (footer is also fine, though there is a minimum height for embeds, making text in footer-only embeds look really small.)
gdude2002 commented

While this issue as written is technically possible, it's not currently a good match for the pagination API, and would require a lot of breaking changes. However, this issue was created as a result of a discussion on Discord, where @beerpiss requested the ability to display multiple embeds ("pages" or "chunks") per user page.

This has been implemented as of 1.7.2-SNAPSHOT, via a new chunkedPages property in all paginator builders. This defaults to 1, but may be set as high as 9 to display up to that many page embeds per user page. This also correctly handles situations where the number of defined pages doesn't neatly divide into the chunk size provided.

When the chunk size is greater than 1, the generated text that usually appears in paginator footers will instead be placed in a separate embed.

I'm closing this issue now, as the original use-case for the discussion has been met. However, this may be revisited at a later time if the need for fully-arbitrary pages (and the energy required to implement them) comes around.