List for cgit developers and users
 help / color / mirror / Atom feed
From: john at keeping.me.uk (John Keeping)
Subject: [RFC] ui-repolist: Allow sections to be collapsible
Date: Mon, 8 Aug 2016 09:44:24 +0100	[thread overview]
Message-ID: <20160808084424.w3jl3lnm4ioopl56@john.keeping.me.uk> (raw)
In-Reply-To: <d89bbd7d-4b99-16f0-92ba-044f04511488@linaro.org>

On Sun, Aug 07, 2016 at 10:02:34PM -0500, Andy Doan wrote:
> On 08/07/2016 02:57 PM, John Keeping wrote:
> > On Sun, Aug 07, 2016 at 02:33:41PM -0500, Andy Doan wrote:
> >> This is a rough work-in-progress, but I wanted to get our take on whether
> >> or not you'd be interested in this type of functionality:
> >>
> >> The index page can be difficult to navigate for really large git
> >> servers. This change allows a configuration like:
> >>
> >>  section-collapse=people
> >>  section-collapse=tests
> >>
> >> And an index page would only display the "people" and "test" section
> >> headers entries (not their repos) with a hyperlink that can be used to
> >> drill down into each section.
> >
> > My initial thought is that the name is wrong, when I saw the summary I
> > assumed it would be about adding script to allow sections to be
> > dynamically expanded/collapsed.  I can't immediately think of a better
> > name, though.
> 
> I originally thought to just send the idea, and then I realized w/o code 
> it would be too confusing. I considered using "section-folds" instead, 
> but it didn't seem much better.

Yeah, I thought about "nested" or "hidden" but those seem misleading.
Collapsed may be the best option.

> > I also wonder why this takes a list of sections rather than a global
> > boolean that applies to all sections.  That may be because I tend to use
> > section-from-path though.
> >
> > Overall, the implementation seems remarkably simple (and the change to
> > make section titles into links should probably be a separate patch) and
> > I think it would be reasonable to do something like this.  But I do
> > wonder if a global boolean would make more sense given the range of ways
> > it is possible to configure sections.
> 
> I agree. I don't want to change default behavior of production sites. 
> I'll split this out in my next attempt.

I don't think we need to worry about changing a section heading into a
link, it seems like a reasonable incremental improvement so I wouldn't
worry about making that configurable.  It just seemed like a logically
separate change to me.

> > Do you have a use case that
> > requires only some sections to have their contents hidden in the main
> > index?
> 
> Yes. I manage Linaro's git server[1]. Its sort of grown into something 
> where we have important "advertised" type repos and tons of "personal" 
> repos. I want to keep some of our most important ones visible on the 
> front page, but "collapse" things such as the personal repos. This 
> seemed like the least invasive way to make something like that happen.
> 
> I'll start up a new revision this week with the assumption you aren't 
> totally against the list of sections.

I thought about this a bit more and I wonder if it would be more natural
to configure this with something like:

	section.collapse = 1

We'd need to change the current "const char *section" into something
like:

	struct cgit_section {
		unsigned int collapse : 1;
		char name[];
	};

and I haven't thought too carefully about how exactly we parse the
"section.collapse" directive (e.g. does it apply to the current section
or does it apply to all future sections?  The former seems more natural
initially but the latter would make it useful with section-from-path).

What do you think?


  reply	other threads:[~2016-08-08  8:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-07 19:33 andy.doan
2016-08-07 19:57 ` john
2016-08-08  3:02   ` andy.doan
2016-08-08  8:44     ` john [this message]
2016-08-09  3:28       ` andy.doan
2016-08-09 18:10         ` john
2016-08-09 21:53           ` andy.doan
2016-08-25 14:56           ` andy.doan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160808084424.w3jl3lnm4ioopl56@john.keeping.me.uk \
    --to=cgit@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).