[RFC] ui-repolist: Allow sections to be collapsible

Andy Doan andy.doan at linaro.org
Tue Aug 9 23:53:01 CEST 2016


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)

Okay. I *think* have something inline with your thinking now. Its a bit 
more invasive. I'll send patches in separate email.




More information about the CGit mailing list