Not relevant.
# not relevant
# not relevant
# not relevant
Disclamer: yes, I do know that this property is easily configurable and I can override it. My point is that the default distribution must be as user-friendly as possible.
Default page sizes are confusing. Admin panels are meant to be designed for non-technical staff. Non-technical staff is used to counting things in multiples of tens not twos. E.g. 10, 20, 50, 100, 500.
If you decide to stick to binary-based page sizes then what is the rationale behind having the last item equal to 192? Why not 256 which would be consistent to the previous sequence elements?
Open any admin panel.
Expect to see decimal-based page sizes.
Page sizes are binary-based.
Never noticed it, but indeed, that's quite weird. No idea about 192, which is even weirder. Can you have a look at the history?
With no explanation in the commit message or docs I guess? Then it's ok to change. That wouldn't even be a bc-break IMO
@greg0ire I was able to find that it was decimal-based in the past but I wasn't able to actually find what happend next yet.
git log -G perPageOptions -p ?
Yields 5e9ce9f86897a06361c64300c46209bb114fce96
I guess it has to do with mozaic mode needing to display nicely. All these numbers are divisible by 4
I think you could either make a PR to add a comment explaining these slightly WTF values, or one that would introduce separate options depending on the current mode.
Seems like 256 will fit nicely with 32 items per page.
B.t.w. git log -G perPageOptions -p returned other commit to me. Should I have activated some specific branch beforehand?
Should I have activated some specific branch beforehand?
No, it's normal, it show all the commits that have a change that contains this. I hand picked this one after a cursory glance at this output.
@greg0ire thanks for help!
My pleasure, thanks for caring :)
Could be solved by changing 192 by 256
Most helpful comment
I guess it has to do with mozaic mode needing to display nicely. All these numbers are divisible by 4