List for cgit developers and users
 help / color / mirror / Atom feed
From: andy.doan at linaro.org (Andy Doan)
Subject: [RFC] ui-repolist: Allow sections to be collapsible
Date: Thu, 25 Aug 2016 09:56:22 -0500	[thread overview]
Message-ID: <59abf58d-f730-49f4-129e-3fd6068267bf@linaro.org> (raw)
In-Reply-To: <20160809181008.i6ck5zh3umxso53l@john.keeping.me.uk>

On 08/09/2016 01:10 PM, John Keeping wrote:
> On Mon, Aug 08, 2016 at 10:28:17PM -0500, Andy Doan wrote:
>> On 08/08/2016 03:44 AM, John Keeping wrote:
>>> 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?
>>
>> I'm a little confused, but its probably my lack of experience with cgit
>> configuration capabilities. I currently take advantage "scan-path" to
>> find everything so I was using something like:
>>
>>   section-from-path=1
>>   scan-path=/srv/repositories
>>   section-collapse=pkg
>>   section-collapse=people
>>   section-collapse=ubuntu
>>
>> I'm not sure how I could accomplish that with your suggestion?
>
> That might be covered by my "haven't thought too carefully", but I was
> thinking of maybe setting "section.collapse = 1" and then any new
> sections created by scan-path would have that bit set.
>
> However, that would require you to have separate scan-path directives to
> find the repositories that should collapse and those that shouldn't.
>
> I think you've convinced me that listing section names in the config is
> the way to go.  But I still think we should invent the cgit_section
> structure to hold the configuration, presumably accessed via a function
> like:
>
> 	struct cgit_section *get_or_create_section(const char *name)

Hey John - I think I've addressed this in these two changes, but I think 
they may have gotten missed while you were on holiday:

  https://lists.zx2c4.com/pipermail/cgit/2016-August/003236.html
  https://lists.zx2c4.com/pipermail/cgit/2016-August/003237.html



      parent reply	other threads:[~2016-08-25 14:56 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
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 [this message]

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=59abf58d-f730-49f4-129e-3fd6068267bf@linaro.org \
    --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).