Show nested projects co-located and indented

[jtulach]

• this PR is implementation of @mbien's idea
  • sorting of project is changed so nested projects are co-located next to each other
• however just co-locating isn't enough to express which project is nested to each
  • as such we also need to show indentation of nested projects
  • the current idea is based on change to Badgingnode.getHtmlDisplayName() and comes from @neilcsmith-net comment
  • that gives the user a clue of the project relations
• while it keeps the overall presentation unchanged
  • except the prefixed HTML name and different sorting the project view behavior remains the same
• no API changes are needed
  • that's very encouraging

• write some unit tests
• verify indentation is updated when project list is changed

[svenreimers]

Awesome!

[mbien]

I think this has potential. Since this is solved via UI, it avoids many issues e.g having to think about how to represent open/closed projects in trees etc - it builds on top of the existing logic, project groups etc.

It does also automatically work for gradle too:

Visually it will likely need some tweaks since it moves the expand/collapse control away from the icon (visible only deeper in the tree). Comparison (right is NB 31):

indentation amount could also become a UI property so that it can be easier themed - but this could be done in followups.

[neilcsmith-net]

I think this has potential. Since this is solved via UI, it avoids many issues e.g having to think about how to represent open/closed projects in trees etc - it builds on top of the existing logic, project groups etc.

+1

Visually it will likely need some tweaks since it moves the expand/collapse control away from the icon (visible only deeper in the tree)

This is my concern too, but it's more than just "visual" in the sense that it affects also where you can click to control expansion. We'll end up with a tree UI that diverges more and more from the underlying model. That might start to get "interesting".

The other UI thought that comes to mind with this is the potential to change the root of the project tree to just one project / subproject, with a breadcrumb bar (similar to eg. the GNOME file browser in list mode when tree expansion is enabled).

[jtulach]

@svenreimers, @mbien and @neilcsmith-net wrote:

Awesome!
I think this has potential.
+1

• thanks guys
• your support shows this area desparatelly needs an improvement
• I'll do my best to deliver.

@mbien wrote:

solved via UI, it avoids many issues

• exactly, I believe this approach is much more doable than LogicalViewProvider.WithNestedProjects allows one to logically nest projects #9592
• as it has far less unknowns than LogicalViewProvider.WithNestedProjects allows one to logically nest projects #9592

@mbien and @neilcsmith-net wrote:

Visually it will likely need some tweaks since it moves the expand/collapse control away
it affects also where you can click to control expansion

• alas, that's true
• I have never been a hard core "pixel perfect" person...
  • mostly due to my sight handicaps which are only getting worse
• ... but yeah, from UX perspective the space is far from ideal
• I'll do something with it!
  • but I try to keep the change simple (e.g. avoid breadcrumbs and other bigger changes in this PR)

[neilcsmith-net]

Firstly, thank you for looking at this. It's a long-standing request, and an option to provide it is much needed. I don't want it to come across as negative if I say that both approaches are flawed in my opinion - I think the actual solution lies between the two. This PR is changing the behaviour in the right place, so it just works for all project types, but I still think it should affect the node model.

If you do want to keep this entirely visual then I think using whitespace indenting is the wrong approach. If it's tweaked to move the control, even worse. A tree should behave like a tree! We're going to get issue reports if we break user's expectations there.

An alternative might be to offer the option of a prefix just to the title of the project nodes based on their depth, without indenting the children. Mixed with topological sorting, it covers some of the visual differentiation.

> Project One
> - Child Project One
> - Child Project Two
> -- Grandchild Project
> Project Two

On the other hand, I think the correct approach is to decorate the node model underneath the tree view, so the tree continues to work as expected without any adaptation. I mentioned PackageView on the other PR, because it has this ability to change a tree view to a flat or reduced view using filter nodes. In some ways it seems a good parallel of this problem?

Why not use FilterNodes here too, and allow options to display opened projects inside parent project (if open), both before or after the existing project node children? We can keep the existing flat view, and keep it as default until we're happy this solves all cases.

Doing this would keep the changes localized and allow the project UI to provide a solution for all project types automatically. An API could still be added later if there was a pressing need for project types to be able to customize this in some way later. After we know what type of context information the project type requires to do that well.