SidebarItems section header

[whirlun]

Add an additional section parameter to SidebarItem to convert it into an unclickable widget so it can be used as a section header. It may be better to design a dedicated Section widget for this task but this workaround works well for me now.

Pre-launch Checklist

• I have incremented the package version as appropriate and updated CHANGELOG.md with my changes
• I have added/updated relevant documentation
• I have run "optimize/organize imports" on all changed files
• I have addressed all analyzer warnings as best I could

[Adrian-Samoticha]

Thanks. Does this support headers that allow the user to fold the content like native headers do:

Screen.Recording.2025-01-08.at.14.44.51.mov

And if not, do you think it can be added to your solution easily?

[whirlun]

Thanks. Does this support headers that allow the user to fold the content like native headers do:

Screen.Recording.2025-01-08.at.14.44.51.mov

Sure, I've added this functionality by reusing disclosureItems. Now if section is true and disclosureItems is not null it will have the ability to expand.

Enregistrement.d.ecran.le.2025-01-08.a.1.02.26.p.m.mov

[Adrian-Samoticha]

Wow, that’s great! I’ll review this PR soon.

[tp]

@Adrian-Samoticha Can you please explain why this code would be different from the withValues(alpha:) before?

I can't see how this would not result in the same color, but maybe I am missing something.

Gave this a quick spin in DartPad to verify, but I always end up with the same color in either approach 🤔

[Adrian-Samoticha]

@tp I don’t remember the details, but if I recall correctly, barrierColor wasn’t a standard Color object in this case, but some object that inherited from Color and whose actual color value was resolved at runtime. It was actually correctly resolved (as in, it was resolved to some object that had a property that held the correct value), but was still rendered incorrectly (it was white even in dark mode).

I just forced it to be a standard Color object that is easier to reason about to make sure that it produces the correct color regardless of the app’s current light/dark-mode setting. There may have been a better way to go about this, but this was I believe the simplest approach.