Sidebar should support n levels of nesting to match MacOS UI

[slewallen]

Description

The Sidebar on Mac OS, such as in Mail, allows a full tree UI with n levels of nested nodes. The macos_ui Sidebar is only supporting one level of nesting.

Steps To Reproduce

Add the following snippet to the macos_ui widget gallery:

            SidebarItem(
              label: Text('Level 1 Group'),
              leading: MacosIcon(FontAwesomeIcons.layerGroup),
              disclosureItems: [
                SidebarItem(
                  leading: MacosIcon(FontAwesomeIcons.grid),
                  label: Text('Layer 1'),
                ),
                SidebarItem(
                  leading: MacosIcon(FontAwesomeIcons.grid),
                  label: Text('Layer 2'),
                ),
                SidebarItem(
                  label: Text('Level 1b Group'),
                  leading: MacosIcon(FontAwesomeIcons.layerGroup),
                  disclosureItems: [
                    SidebarItem(
                      leading: MacosIcon(FontAwesomeIcons.grid),
                      label: Text('Object 1'),
                    ),
                    SidebarItem(
                      leading: MacosIcon(FontAwesomeIcons.grid),
                      label: Text('Object 2'),
                    ),
                  ],
                ),

The result is that the 'Level 1b Group' has no disclosure turn-down and no children.

Mail on MacOS, as an example, does support n number of nested nodes.

[GroovinChip]

This is an interesting one...I'm guessing it has to do with how we render the disclosure items:

children: widget.item.disclosureItems!.map((item) {
  return Padding(
    padding: EdgeInsets.only(
      left: 24.0 + theme.visualDensity.horizontal,
    ),
    child: SizedBox(
      width: double.infinity,
      child: _SidebarItem(
        item: item,
        onClick: () => widget.onChanged?.call(item),
        selected: widget.selectedItem == item,
      ),
    ),
  );
}).toList(),

But I would think that this should take care of sub-disclosure items too. @whiplashoo, do you have any thoughts on this?

[GroovinChip]

Also, @slewallen, according to Apple's Human Interface Guidelines there should be no more than two levels of hierarchy in a sidebar. The behavior in Apple's Mail app obviously contradicts this, as Apple often does with their apps 🙄.

We often have to make judgement calls on whether to obey the HIG or follow Apple's lead via their own actual apps, and it's a tough call every time. I welcome anyone's thoughts on the matter.

[slewallen]

The SwiftUI List supports any level of nesting with the sidebar style. The Apple HIG only contains a general guideline for the sidebar. My vote would for the macos_ui Sidebar to have the same capability as the SwiftUI List UI.

    var body: some View {
		List {
			ForEach(categories, id: \.self) { section in
				Section(header: Text(section.value)) {
					OutlineGroup(
						section.children ?? [],
						id: \.value,
						children: \.children
					) { tree in
						Text(tree.value)
							.font(.subheadline)
					}
				}
			}
		}.listStyle(SidebarListStyle())
    }

[edwardaux]

We often have to make judgement calls on whether to obey the HIG or follow Apple's lead via their own actual apps, and it's a tough call every time. I welcome anyone's thoughts on the matter.

I can definitely see that this is a tricky situation. As you say, Apple are often inconsistent in how they implement things and it changes from version to version.

For what it is worth, though, here's my 2c... I've implemented a number of native mac apps and I always treat the HIG as a guide (the name itself gives it away - human interface /guidelines/). There will always be cases where there are valid reasons to stray from the default guidelines.

To me, it makes total sense for the default values/settings for macos_ui to be based on the HIG, however in my opinion all of those values should be able to be overridden if the developer desires.

Another example along the same lines was in a recent PR to allow overriding the disabled colour - there was some excellent discussion about whether changing the colour is the "right" solution, but even if there are other UX options, I believe the framework should allow overriding the settings (whether that be via constructor values, theme values, or both).

Of course, I'm not saying that my opinion is the "right" one... I just thought I'd share my thoughts in response to your request for feedback. As the library maintainers, you'll ultimately have to make a decision about just how opinionated the library is.