Re: [Buildroot] [PATCH v3] support/scripts/pkg-stats: migrate to CSS grid and inline javascript

[Thomas Petazzoni via buildroot <buildroot@buildroot.org>]

Sen,

On Sun, 24 Jul 2022 09:36:20 -0500
Sen Hastings <sen@phobosdpl.com> wrote:

> >  * Sorting is now very slow, to the point that Firefox complains that
> >    the page is slowing down the web browser. It was instantaneous in
> >    the old code, but way faster.>  
> 
> Wow, dang I see what you mean. I was doing testing with relatively
> *small* defconfigs. Looks like the bottleneck is actually at the end
> when calling packageGrid.append(element). I'll dig into it.

Thanks:

> >  * The "Latest version" cell is no longer with a dark orange/red
> >    background when the version doesn't match with the "Current
> >    version", these cells now have a green background, making one think
> >    that the package is up-to-date in Buildroot.
> >   
> Ah, that's a cascade order issue. Fix is to move the
> ".correct, .nopatches, .good_url..." rule above the
> ".wrong, .lotsofpatches, .invalid_url..." rule.

OK. I guess you'll send a patch to fix this.

> >  * When sorting on a column, a small arrow appears indicating that the
> >    sorting has been done based on this column. But then when you sort
> >    by another column, the arrow appears on this new column, but doesn't
> >    disappear on the old one, so you no longer know which column was
> >    using for the sorting.
> >   
> This is *kind of* a feature? sortGrid()'s sorting is cumulative, so they
> are all *technically* being used for sorting. This means the table is
> not *reset* to its original state before every sort.
> For example, sorting by (clicking on) "Infrastructure", then "License"
> will yield a different sort (row order) than sorting by "License",
> *then* "Infrastructure". An actual table "reset" is achieved with
> sorting by "Package" ascending (down arrow). I must admit though, after
> the table is reset the other arrows are meaningless until clicked on
> again. That is definitely misleading, so no matter what arrows *should*
> be reset after a table reset. I guess I didn't realize my sort behaved
> differently in this regard. Whatever behaviour you think is most
> appropriate (the original or cumulative), I'll make it do that.

Yeah, Arnout told me the same thing, but I find that not obvious.
Indeed, you then simply have arrows on two (or more) columns, and then
don't remember which one you clicked first, and which one you clicked
afterwards. So basically, if you don't remember in which order you
clicked, you have no idea based on what sorting rules the current table
is listed.

> > Do you think you could have a look at those issues?
> >   
> Yes. As a clerical note, should I do multiple patches, a patch series or
> one big one?

Either multiple separate patches sent individually, or grouped as a
patch series, but not a "big one" :-)

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot