Works fine.
I would prefer a separate flat/tree setting (even if switching may require one more step):

When sorting by status, Range should be at the bottom.
Sort modified Both,B,A, then New etc. Why submodules separate (there are no special icons, should be handled as modified with both/B/A)?

Can rangediff be in top view, no need for a folder?
Similar for groups with just one item (but may not be feasible there).

Nice that collapsing is automatic, but skip the folder icon

When scrolling to next, nice that next group expands.
It would be nice to have collapse/expand as for side panel

Should selecting a folder with leafs have some info in the fileviewer? First file?
Action when rightclicking should be as if all subnodes are selected.
So maybe selecting a folder selects all nodes?

RangeDiff should have a new icon, reusing it for yet another purpose is a little confusing (since is was added for groups)

Works fine. I would prefer a separate flat/tree setting (even if switching may require one more step):

Opening a submenu of a context menu would be a pretty expensive second step.
I could add an additional context menu item "As tree" (but will be much code).

When sorting by status, Range should be at the bottom.

I agree.

Sort modified Both,B,A, then New etc. Why submodules separate (there are no special icons, should be handled as modified with both/B/A)?

I do not fully understand the point about submodules. It might become resolved when considering the DiffStatus for the grouping, too.

Can rangediff be in top view, no need for a folder? Similar for groups with just one item (but may not be feasible there).

👍 Should not be difficult for grouping (same as the already implemented handling if there is only one group).

It would be nice to have collapse/expand as for side panel
Action when rightclicking should be as if all subnodes are selected. So maybe selecting a folder selects all nodes?

I am adding Collapse, Expand and Select all. In the follow-up for adding a file-tree mode or later, special menu items or behavior can be added.

Should selecting a folder with leaves have some info in the fileviewer? First file?

Yes, if one has a good idea. But not the first file - same as in the "File tree".

RangeDiff should have a new icon, reusing it for yet another purpose is a little confusing (since is was added for groups)

I agree. My main use of range diff is to see equal (and skipped) revisions. So a different icon would be good. Proposals?
For the additional diff groups, I was thinking of overlays "B", "A", "C"ombined. An "R" overlay might suffice for range diff, too.

Opening a submenu of a context menu would be a pretty expensive second step. I could add an additional context menu item "As tree" (but will be much code).

I meant a separate menu on the top level, as appearance

I do not fully understand the point about submodules. It might become resolved when considering the DiffStatus for the grouping, too.

I consider a changed submodule as a changed file.
There is no special icon for both changed (or only A/B) for submodules

RangeDiff should have a new icon, reusing it for yet another purpose is a little confusing (since is was added for groups)

I agree. My main use of range diff is to see equal (and skipped) revisions. So a different icon would be good. Proposals? For the additional diff groups, I was thinking of overlays "B", "A", "C"ombined. An "R" overlay might suffice for range diff, too.

Overlay in general would be good for these icons. The variants (both changed etc) need to be changed for dark mode anyway.
I am not a designer, it takes time to get opinions and a lot more to implement changes, so no great proposal myself.

Right click on folder should enable more context menu options

This is new functionality, nice to have for RevDiff but needed if FileTree is updated too (or integrated in RevDiff).
Add todo in Description?

A few comments on this PR as it is now:
[ ] Remove folder icons for files, appears on the first items
[ ] Remove icons if top is matched (file status, will affect all but submodules)
[ ] Lazy for GitItemStatus #12116 (comment)
[ ] Comment for the unexpected shift-click behavior
* The dependency is fine in principle, need to check some details.

Questions:

• Should changed submodules be in modified status gruop? Now they are separated
  * Separate the flat/tree setting?

For future PRs?
* context menu for folders #12116 (comment)

• Optional group for all files, to replace file tree tab (maybe). Added similar to grep, i.e. after diff.

--
For first item

Thank you for the detailed feedback. I am aware of the TODOs.

TreeView has several limitations, particularly icons:
StateImages are limited to 14 (only a runtime error when trying to use a higher index). StateImages are scaled in a special way.
Images work better. But it looks ugly if some nodes have no icon.
With OwnerDrawAll, one needs to draw everything including tree lines, which feels like implementing the tree view control from scratch, what I do not want to do.

Tooltips are automatically provided - if Text matches the owner-drawn length. I saw the wrong selection highlight length, too. I am adapting this.

Should changed submodules be in modified status group? Now they are separated.

"Sort by status" is a TODO yet and should yield the same ordering as before. New subgroups or changes in the ordering should be added in a follow-up.

Separate the flat/tree setting?

I prefer a one-stop shop. A "tree / flat" toggle could be useful in addition.
Later, we should add a toolbar with sort options and filtering.
FormCommit and artificial commits could use a separate sorting setting.

folder icons for files, appears on the first items

If a file is the only file in a subfolder, no subfolder-node is created but the folder icon is added to the file as StateImage (with arbitrary scaling by the TreeView control).
Without the folder icon, one could miss the fact that the file is located in a subfolder.

(sorted by path)

(grouped by status)

It is not the "first" item but a single item - between the surrounding sibling folders:

Not used in flat view:

Should changed submodules be in modified status gruop? Now they are separated

I think the current sorting is the same as in master.

The mentioned more logical sorting could simply be achieved in a separate PR by moving up the submodule icons in CreateImageListData.

I prefer current order changed,added,removed then by both,B,A

Then we could remove DiffStatus from GetStatusKey again and rely on the order of images in CreateImageListData.

            (string imageKey, Bitmap icon)[] images =
            [
                (nameof(Images.FileStatusUnknown), ScaleHeight(Images.FileStatusUnknown)),
                (nameof(Images.FileStatusModified), ScaleHeight(Images.FileStatusModified)),
                (nameof(Images.FileStatusModifiedOnlyA), ScaleHeight(Images.FileStatusModifiedOnlyA)),
                (nameof(Images.FileStatusModifiedOnlyB), ScaleHeight(Images.FileStatusModifiedOnlyB)),
                (nameof(Images.FileStatusModifiedSame), ScaleHeight(Images.FileStatusModifiedSame)),
                (nameof(Images.FileStatusModifiedUnequal), ScaleHeight(Images.FileStatusModifiedUnequal)),
                (nameof(Images.FileStatusAdded), ScaleHeight(Images.FileStatusAdded)),
                (nameof(Images.FileStatusAddedOnlyA), ScaleHeight(Images.FileStatusAddedOnlyA)),
                (nameof(Images.FileStatusAddedOnlyB), ScaleHeight(Images.FileStatusAddedOnlyB)),
                (nameof(Images.FileStatusAddedSame), ScaleHeight(Images.FileStatusAddedSame)),
                (nameof(Images.FileStatusAddedUnequal), ScaleHeight(Images.FileStatusAddedUnequal)),
                (nameof(Images.FileStatusRemoved), ScaleHeight(Images.FileStatusRemoved)),
                (nameof(Images.FileStatusRemovedOnlyA), ScaleHeight(Images.FileStatusRemovedOnlyA)),
                (nameof(Images.FileStatusRemovedOnlyB), ScaleHeight(Images.FileStatusRemovedOnlyB)),
                (nameof(Images.FileStatusRemovedSame), ScaleHeight(Images.FileStatusRemovedSame)),
                (nameof(Images.FileStatusRemovedUnequal), ScaleHeight(Images.FileStatusRemovedUnequal)),
                (nameof(Images.Unmerged), ScaleHeight(Images.Unmerged)),
                (nameof(Images.FileStatusRenamed), ScaleHeight(Images.FileStatusRenamed.AdaptLightness())),
                (nameof(Images.FileStatusRenamedOnlyA), ScaleHeight(Images.FileStatusRenamedOnlyA)),
                (nameof(Images.FileStatusRenamedOnlyB), ScaleHeight(Images.FileStatusRenamedOnlyB)),
                (nameof(Images.FileStatusRenamedSame), ScaleHeight(Images.FileStatusRenamedSame)),
                (nameof(Images.FileStatusRenamedUnequal), ScaleHeight(Images.FileStatusRenamedUnequal)),
                (nameof(Images.FileStatusCopied), ScaleHeight(Images.FileStatusCopied)),
                (nameof(Images.FileStatusCopiedOnlyA), ScaleHeight(Images.FileStatusCopiedOnlyA)),
                (nameof(Images.FileStatusCopiedOnlyB), ScaleHeight(Images.FileStatusCopiedOnlyB)),
                (nameof(Images.FileStatusCopiedSame), ScaleHeight(Images.FileStatusCopiedSame)),
                (nameof(Images.FileStatusCopiedUnequal), ScaleHeight(Images.FileStatusCopiedUnequal)),
                (nameof(Images.SubmodulesManage), ScaleHeight(Images.SubmodulesManage)),
                (nameof(Images.FolderSubmodule), ScaleHeight(Images.FolderSubmodule)),
                (nameof(Images.SubmoduleDirty), ScaleHeight(Images.SubmoduleDirty)),
                (nameof(Images.SubmoduleRevisionUp), ScaleHeight(Images.SubmoduleRevisionUp)),
                (nameof(Images.SubmoduleRevisionUpDirty), ScaleHeight(Images.SubmoduleRevisionUpDirty)),
                (nameof(Images.SubmoduleRevisionDown), ScaleHeight(Images.SubmoduleRevisionDown)),
                (nameof(Images.SubmoduleRevisionDownDirty), ScaleHeight(Images.SubmoduleRevisionDownDirty)),
                (nameof(Images.SubmoduleRevisionSemiUp), ScaleHeight(Images.SubmoduleRevisionSemiUp)),
                (nameof(Images.SubmoduleRevisionSemiUpDirty), ScaleHeight(Images.SubmoduleRevisionSemiUpDirty)),
                (nameof(Images.SubmoduleRevisionSemiDown), ScaleHeight(Images.SubmoduleRevisionSemiDown)),
                (nameof(Images.SubmoduleRevisionSemiDownDirty), ScaleHeight(Images.SubmoduleRevisionSemiDownDirty)),
                (nameof(Images.ViewFile), ScaleHeight(Images.ViewFile)),
                (nameof(Images.Diff), ScaleHeight(Images.Diff))
            ];

I think I have addressed every discussed point.

Regression from #12115: When moving to next file on bottom file with scrollwheel, the selection restarts at the top file.
I implemented it this way in the original PR, but got requests to change.
Now I am used to stop at the bottom file and have been confused a couple of times over the number of changes...

Heading needed in FormCommit for sort by status

Collapsed

Expanded (as it is default, so no major issue)

Heading needed in FormCommit for sort by status

Collapsed

Expanded (as it is default, so no major issue)

Why? Why do we need the separation?

Heading needed in FormCommit for sort by status
Collapsed
Expanded (as it is default, so no major issue)

Why? Why do we need the separation?

When you collapse the group, it looks like something is missing

Why do we need the separation?

In order to be able to collapse an uninteresting group of files instead of scrolling a lot.
These grouping nodes could be omitted in flat mode. I would say they are needed in tree mode.

Heading needed in FormCommit for sort by status

Really? If yes, we will need a TranslatedString for each status image (follow-up PR).
These nodes are expanded on click. I thought this would be self-explanatory enough.

@mstv A little UX improvement that I would like to see added:
When there is only one "Diff" group, clicking on it just select it and do not fold it.
Folding it bring no value (because that's the only thing to display) and if I click on it for any reason, I have to click on it again (and it's frustrating 😉 )

I hope it's not too late to ask. Is it possible to have tree-view as an option? Currently UX has so many subtle and not so subtle sharp edges that it makes it hardly usable (for me).
I've created 3 issues related to this but there are more quirks than that.

I hope it's not too late to ask. Is it possible to have tree-view as an option?

Sorry that it broke how you use it.
It is not too late because the answer is the same: In principle, yes because it is soft ware. But it would be much effort for little benefit.

Multi-selection works with Ctrl+click and Shift+click. (Ctrl+A works the same as before.)
At least with #12149, I do not see much need for or value in features like

• be able to have no selection
• select multiple entries from bottom with the mouse
  With FileStatusList: Add toolbar and actions on folders #12149, just select a diff group or a folder and operate on all contained items.
  It should not be too difficult to add a generic click and drag for selecting multiple files - to MultiSelectTreeView.
  (Though changing the focused node on mouse down is hard to achieve with TreeView.)

The tree expand/collapse action must be bound to a double click not a single click. Otherwise, it's extremely annoying....

Also, note the selected image background - it doesn't look being correctly reset.

The tree expand/collapse action must be bound to a double click not a single click.

This is only if there multiple diff groups. There is no real use case to select an expanded group other than collapsing it.

Also, note the selected image background - it doesn't look being correctly reset.

This is Windows Explorer style.
This TreeView is just used in TreeViewDrawMode.OwnerDrawText. The TreeView lives its own life (as have already complained).

I update #12150 with the inactive selected in FileStatus

This is only if there multiple diff groups.

Implemented in #12149.

I update #12150 with the inactive selected in FileStatus

(I am not completely sure about what you are going to.)
If there is no item selected, no TreeNode shall be highlighted. This is important for the UX in FormComit.

The tree expand/collapse action must be bound to a double click not a single click.

This is only if there multiple diff groups. There is no real use case to select an expanded group other than collapsing it.

First and foremost, this is an accessibility issue. Users (like me in this case) can click on the group accidentally.
Secondly, this is behaviour is inconsistent with other part of the app - we have groups in the Diff tab and we have a treeview in the left panel, and none of those collapse on a single click.

Groups in the Diff tab were collapsible with single click - but only if all filenames fit into the control. This limitation used to be a nuisance.

Enabling ShowRootLines (as in Left Panel) if there are multiple diff groups, would enable collapse/expand with single click - but would waste precious horizontal space.

I have restricted the single-click collapse/expand to the icons of the root nodes (added to #12149).

We lost the feature to be able to drag a file from the tree (and drop it in an external application).

The whole mechanic of staging/unstaging has been seriously affected, which has significant usability implications.
That is, when the files were in a flat list, it was easy and natural just to double click on a file to stage/unstage.

The new UI introduced the concept of folders, which traditionally (i.e., in Windows) have a different meaning for double-click (if clicked on a icon/text and not on the [+] button) - that's expand/collapse/open.
Having a single-click on a folder node is a frustrating experience, so it has to remain (or be reinstated).
It's still possible to double-click on a file, but it's not possible to stage/unstage a folder - not with a button or by any other means.

Try #12149, please.