The interfaces for Favorites should be changed to be unified and also to more effectively differentiate between identically-named favorites

[godotdot]

Describe the project you are working on

A project that builds on some reusable resource, i.e. a library of code, scenes, or media, and uses favorites in the library and elsewhere that may share names.

Describe the problem or limitation you are having in your project

Two issues:
1 - The current manner in which favorites are displayed is inconsistent.
For instance, the filesystem UI just makes them an another branch of the tree, but the file dialog UI does something different; I think it's just a list in its own section of the UI.

2 - Items added to favorites do not indicate their path, just their name.
So if multiple favorite items are located in different folders but have the same name, it is inconvenient to determine which is which.
For instance, if both lib/AI and game/AI were favorites, then favorites would display "AI, AI" in the list.
To give a somewhat (though not entirely) absurd example, it is very possible to end up with stuff like:

This is particularly frustrating when using the file dialogs, e.g. when creating a new node or opening a file, as the only way to determine which is which, is by clicking each one until finding the one that is desired.

It is less of a nuisance in the filesystem UI, since mousing over a favorite shows a tooltip that displays the path to the file. This is better, but it still requires user interaction, and is still kind of slow as the tooltips don't appear instantly.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Replacement/Unification

A new UI for Favorites would be created.
It would replace the current set of UIs for Favorites.

This has the following benefits:

1. Consistency for the user and code reuse for Godot's developers.
2. It would move display of favorites from the filesystem UI and into its own UI. Since the favorites would instead be displayed in a separate UI, that UI could always be visible even after navigating or scrolling deep into the filesystem UI, which would be beneficial.
3. It would remove the concept of favorites from the filesystem UI. This should simplify the filesystem UI a little. The filesystem UI already seems to not treat favorites the same as files, (e.g. it just filters out even matching favorites when you search, for instance), so it might not be very important for favorites to be integrated into that UI.

Design/Implementation

This new Favorites UI would be a Tree with 3 columns: Name, Short/Unique Path, and Full/Absolute Path.
Name and Full Path should be self-explanatory, but Short Path is not, so I'll explain.

It is necessary for the sake of users to disambiguate same-named favorites, and the path is the differentiator.
Showing the full path, however, may be cumbersome if it is long enough or redundant enough.

Short Path is meant to ameliorate that by only showing the minimum section of the path required to disambiguate favorites; for instance, in the case of a favorite that does not share its name with any others, Short Path would be the empty string. In the case of long_common_path/less_common_path/lib/AI and lib/AI both being favorites, the Short Paths would be less_common_path and lib respectively.

Sorting

Currently favorites are sorted in the order in which they are added.
I think there could be a benefit to allowing sorting by each column. In such a case, it would sort first by column and further sort by name. For instance, sorting by Full Path would effectively group all favorites that share a path, and sort them by name, so you'd end up with an ordering like:
a/AI
a/Sounds
a/Weapons
a/a/AI
a/a/Sounds
a/a/Weapons
a/b/AI
a/b/Sounds
a/b/Weapons

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

It would look somewhat like this:

I suspect in most cases it would only be expanded enough to show part of the Full Path; scrolling capabilities and/or tooltips could be useful in cases where people care about that information but don't want to fill their screen with it.

If this enhancement will not be used often, can it be worked around with a few lines of script?

I believe it would be used all the time.

Is there a reason why this should be core and not an add-on in the asset library?

I believe it would be used all the time; also, I don't know the feasibility of implementing it as an add-on, given it is meant to replace existing functionality.

[zinnschlag]

This UI design takes up a lot of screen real estate. Even if you can scale the window down to ignore the 3rd column it seems wasteful and a bit impractical.

I don't think the full path is actually useful. Name and short path should be sufficient to identify a favourite. And while we are at it, why not combine short path and name: less_common_path/lib/AI. A single column. Wastes no space and fits well into a narrow dock (including the existing layout of the open file dialogue). There could be a new editor setting to either sort by name or by short path first.

Other than the overly generous screen space usage, not a bad idea.

[godotdot]

Thanks for your feedback.

My concern with only showing the short path is that path only disambiguates between favorites, but it may make it unclear or confusing exactly what the favorite is.

For instance, given a file structure like:
common_path/uncommon_path/Sounds
common_path/Sounds
Sounds

If only one of those was a favorite, it would appear as Sounds and the short path would be the empty string (at least, as I defined short path's behavior). That's why I also included the full path.
Is such a file structure likely? Probably not, but if it occurred, it would be confusing not to have the full path.

[godotdot]

Thinking more about this, I have another idea that may actually be much better:

If users could specify the names of favorites, they should be able to disambiguate them in whichever manner they might desire.

This would be nice not only for disambiguation between identically-named resources, but to give resources names that are more meaningful to the user (e.g. in the case of using third-party resources that may have names that don't make sense to the user).

Not only should this allow much greater clarity, it would avoid needing to display any paths whatsoever, though it might still be useful to do that with with a tooltip.

I supposed there is the disadvantage that multiple users of the same project might have disagreements regarding which names they'd prefer to use, but that can happen with the names of anything under such circumstances, I guess.

[Calinou]

I think disambiguating paths that are identical is a good idea (this is already done within the script editor), but the rest of the proposal seems pretty complex to me.

[godotdot]

I think disambiguating paths that are identical is a good idea (this is already done within the script editor), but the rest of the proposal seems pretty complex to me.

I'm not quite sure which part of this you are referring to, because I kind of switched things up a bit in the comments a few minutes ago.

Are you referring to the original proposal (columns for Name, Short Path and Full Path), or the latest (allowing renaming the favorites)?

I would think renaming would not be terribly complicated, though I could be mistaken.

If taking the renaming approach, I'd think the rest of the proposal would basically turn into using a single type of UI for favorites instead of having different ones for the filesystem and file dialog.

The main advantage of that would be to always be able to see favorites even if one had navigated deep into the filesystem UI, since it'd be a different UI from that.
It wouldn't be necessary, though; it'd be fine to just implement the renaming. I just think it'd be nice to not have the filesystem UI and the favorites integrated, for the reason stated.

[timothyqiu]

I love how Blender handles the duplicated folder name issue: it simply allows you to rename the favourites list item by double clicking. The full path and "Double click to rename" hint is shown in the tooltip of list item.

[godotdot]

I love how Blender handles the duplicated folder name issue: it simply allows you to rename the favourites list item by double clicking. The full path and "Double click to rename" hint is shown in the tooltip of list item.

At this point I really think that would be the best solution.

[godotdot]

Another thought, to go along with renamable favorites: would it be useful to be able to create folders to organize favorites into?