Konstantin Ryabitsev wrote:
> Hello:
>
> I switched the configuration to return wwwlisting as toplevel view (instead of
> redirecting / to /all/), but there's some discontent, because the easy
> interface to "search everything" is gone and unless someone knows about /all/,
> they wouldn't find out about it from the wwwlisting view.
>
> How about, if there is an extindex "all" defined, the wwwlisting adds an extra
> search box:
>
> [_________________] [search all] help
>
> * 2021-08-26 16:54 - https://x-lore.kernel.org/all/
> All of lore.kernel.org
>
> ------------------------------------------------------
>
> [_________________] [locate inbox]
>
> * 2021-08-26 16:54 - https://x-lore.kernel.org/lkml/
> [description]
> [infourl]
I think that's too much vertical whitespace at the top of the
page, and multiple <form>s or <input> boxes at the top can get
confusing.
Just making /all/ show up at the top like a normal inbox (and
letting the admin decide on description) seems sufficient. If
users can get to /all/ then they can search /all/ as normal.
I tried moving the <input>s next to infourl, but mixing <form>
and <pre> introduces a lot of vertical whitespace.
I also tried adding radio button (or drop-down):
[_________________] [*] inboxes [ ] /all/ [search]
But extra <form> elements always confuse me whenever I encounter
them in any browser, so I decided to just leave things alone.
Eric Wong (2):
www_listing: show ->ALL at top of HTML listing
www_listing: fix odd "locate inbox" cases
lib/PublicInbox/WwwListing.pm | 50 +++++++++++++++++++++++------------
t/extindex-psgi.t | 12 +++++++++
2 files changed, 45 insertions(+), 17 deletions(-)
--
unsubscribe: one-click, see List-Unsubscribe header
archive: https://public-inbox.org/meta/
