Add Collapse Support to ListViewGroup

[lonitra]

Is your feature request related to a problem? Please describe.

As of now, there's not an option for a user to hide items under a ListViewGroup that they aren't interested in seeing at the time, similar to what windows like File Explorer provide. This could result in endless scrolling if there are many ListViewGroups and many items under each group. As #2623 suggested, a collapsible/collapse property would be a nice touch to give users flexibility and can especially be useful for clutter management purposes.

Describe the solution you'd like

Add the ability for users to make items in a group collapsible.

API:

public class ListViewGroup 
{
    public bool Collapsible { get; set; }
    public bool Collapsed { get; set; }
}

Example:

var lvGroup = new ListViewGroup 
{
    Collapsible = true,
    Collapsed = false
};

An excellent visualization of what this might look like from the original issue:

Will this feature affect UI controls?

Yes.

Will VS Designer need to support the feature?
It would be nice. I would imagine the Designer would have an area carved out in the ListViewGroup Collection Editor where Collapsible/Collapsed can be toggled. Something like so:

I also imagine that the changes would immediately visible to the user in the designer, again similar to what is shown in the original issue.

What impact will it have on accessibility?
I'm not quite sure here.

Will this feature need to be localized or be localizable?
Aside from some work relating to accessibility namely perhaps what a talkback would use to describe the property, no I do not think this needs to be localized/localizable.

---

Update
After implementing Collapsible/Collapsed property for ListViewGroup as done so in #3155 , we realize that this will be an issue with the design-time serializer, which orders properties assignment statement alphabetically. This means that Collapsed will come before Collapsible.
Suppose a user wanted to set the properties like so in designer:

The serializer will generate:

this.listViewGroup1.Collapsed = true;
this.listViewGroup1.Collapsible = true;

Since Collapsed is no-op when Collapsible = false (which is the default), the end result will be Collapsed = false and Collapsible = true , not what the user intended.

Suggestion
Upon discussion with the team, we came to the idea to merge the two properties into one. The new API will be as follows:

public class ListViewGroup 
{
    public enum ListViewGroupCollapsedState 
    {
        DEFAULT,
        EXPANDED,
        COLLAPSED
    }

    public ListViewGroupCollasedState CollapsedState { get; set; }
}

[weltkante]

What impact will it have on accessibility?

It will be needed to be presented though accessibility API that you can toggle the collapsed state of a group.

[merriemcgaw]

We'll need to see if we can expose the UIA Expand/Collapse pattern. You can chat with @M-Lipin for suggestions when you're at that point.

[RussKie]

I've scanned the neighbouring API and the ListView et al API have the following public surface:

• bool ListView.AutoArrange
• bool ListView.CheckBoxes
• bool ListView.LabelWrap
• bool ListViewItem.Checked
• bool ListViewItem.Focused
• bool ListViewItem.Selected

so the proposal to add the following fits right in:

• bool ListViewGroup.Collapsible
• bool ListViewGroup.Collapsed.

It should be noted that TreeNode appears to favour IsXyz naming convention, that feels inconsistent for the current context:

• bool TreeNode.IsEditing
• bool TreeNode.IsExpanded
• bool TreeNode.IsSelected, etc.

I believe we should follow the former naming than the latter.

[terrajobst]

After implementing Collapsible/Collapsed property for ListViewGroup as done so in #3155 , we realize that this will be an issue with the design-time serializer, which orders properties assignment statement alphabetically.

When we approved it, I wrote this in email:

Please don’t throw exceptions when Collapsible == false and Collapsed is set. Properties should be settable independently. Ideally, Collapsed is a no-op when Collapsible is false, but as soon as Collapsible is set to true, the state currently stored in Collapsed is respected.

The mental model I had in mind was something simple like this:

public bool Collapsible 
{
    get => _collapsible;
    set
    {
        if (_collapsible != value)
        {
            _collapsible = true;
            UpdateGroupState();
        }
    }
}

public bool Collapsed
{
    get => _collapsed;
    set
    {
        if (_collapsed != value)
        {
            _collapsed = true;
            UpdateGroupState();
        }
    }
}

private void UpdateGroupState()
{
    // Use _collapsible && _collapsed
}

[RussKie]

The mental model I had in mind was something simple like this:

public bool Collapsible 
{
    get => _collapsible;
    set
    {
        if (_collapsible != value)
        {
            _collapsible = true;
            UpdateGroupState();

Yes, it is something I had in mind too.
However as we started exploring the designer story we come to realisation that correlated properties pose challenge to the designer. It was also uncovered that we completely overlooked the events associated with the properties.

The new proposal is to meld the two properties into one, thus reducing the API surface and make it easier for a developer:

public enum CollapsedState 
{
    None = 0,
    Expanded,    // collapsible
    Collapsed,   // collapsible | collapsed
}

public CollapsedState CollapsedState
{
    get => _collapsedState;
    set
    {
        if (_collapsedState!= value)
        {
            _collapsedState = value;
            OnCollapsedStateChanged(value);
            UpdateGroupState();
        }
    }
}

public EventHandler<ListViewGroupCollapsedStateArgs> CollapsedStateChanged(ListViewGroupCollapsedStateArgs e);