Help user differentiate shared reference points in wizard to chose the local reference point mapping

[tobous]

trafficstars

As part of the migration to the reference-point-based resource model, #1037 adjusted the UI to choose the local representation of shared reference points.

With the new sharing model, reference point names are not as significant/meaningful as before as the user can now chose any directory as a reference point. As a result, the situation where there are multiple reference points with the same name (e.g. all named src) is a probably scenario. This leads to issues with the new dialog to chose the local mapping as the user has no way of differentiating the tabs, i.e. they have no way of telling which tab corresponds to which actual folder chosen by the sender of the negotiation.

Proposed Solution

To alleviate this issue, it would be helpful to give the user tools to differentiate the tabs.

First of all, they should be able to differentiate the tabs locally. This could be done by providing additional information about the corresponding folder on the sender side or by simply numbering the tabs with the same name.

Secondly, the users should be able to better tell which resource the sender chose. This can be done by displaying additional information about the resource. Good candidates would be:

• The workspace-relative path on the sender side.
• The resource tree represented by the reference point.

I would suggest providing both information to give the best chance of identifying the resource. How this information is presented in a useful way without overwhelming the user still has to be determined.

(Using the workspace-relative path of the reference point on the sender side could be seen as questionable as it "leaks" information of the sender workspace that is explicitly not part of the session, but, based on the assumption that a very common use case is working on already existing/shared code base, this should not be a very big concern while providing a major usability improvement. Furthermore, the shared information should be of no real (other) value to the receiving side as the path is still workspace-relative and escaped to using / as the separator, meaning it does not even contain any information about the filesystem of the user.)