Show matching icons based on the filename in the repo tree view

[yardenshoham]

• Adds functionality that renders file and folder icons according to their name in the repo tree view
• Based on https://github.com/Claudiohbsantos/github-material-icons-extension (which is based on https://github.com/PKief/vscode-material-icon-theme)
• build/generate-svg.js now generate from https://github.com/PKief/vscode-material-icon-theme the:
  • icon map (assets/material-icons.json)
  • icon SVGs
• EntryIcon returns hundreds of different icons, not the old (less than 10) results
• This feature is disabled by default and can be turned on. ui.FILE_ICONS: file-specific: [file-specific, basic]: Whether the file icons in the repo tree view should be specific to the file name (file-specific) or the same icon for all files and another for the folders (basic)
• Closes [Feature] Show matching icons based on the file type  #11149

Before

After (if you set ui.FILE_ICONS = file-specific in app.ini)

[yardenshoham]

The diff is actually pretty small if you don't count the generated files public/img/*.svg and asset/material-icons.json

[lafriks]

Test failure is related

[delvh]

Getting this PR merged will be fun as the two opposing views clash with each other in this PR:
The ones who want this change, and the ones who want to keep Gitea minimal.
I'm somewhere in between.
For me, the usefulness probably outweighs the extra resource usage.

[delvh]

Before you do anything else, @lunny and I meant this a bit different.
Here's my temporary review.

[yardenshoham]

By that logic, we can drop all SVGs...

[delvh]

Well… Yes. But that is basically a PR of its own.

---

As I've already written on Discord, I'm also fine with marking the functionality as deprecated/experimental and subject to change, and then refactoring the mechanism after this PR has been merged.
Given those circumstances, I can re-approve.

---

(The funny thing is: With that, the default value of basic suddenly makes more sense as users then have to opt-in into a potentially breaking mechanism)

[yardenshoham]

Experimental is fine I guess

[wxiaoguang]

If we agree to use "icon pack" solution eventually, does it need to merge these 600+ SVG files now? We would see: this PR: +660 SVG files, next PR: -660 SVG files. 😄

[lunny]

We'd have to build a whole system to map filenames to icons. This is better, simpler, and we don't force it on anyone (it's a setting)

But how to handle these cases:

* Some files are recognized wrong and use non-ideal icons.

* Some users want to use other style icons (eg: do not use icons for some directories).

* Some private instances may have their own private file types and need private icons.

My proposal could include the "rules" json file, keep the icon-detection algorithm here

To be "simple", Gitea could provide an icon package officially, users just need to download it.

Good idea. Could that become a part of theme?

Sorry, I think @wxiaoguang 's idea is better and plugable.

[yardenshoham]

I understand this approach will not be accepted

[wxiaoguang]

@yardenshoham if you don't mind, I would try to implement "icon pack" approach, and re-use your code (co-author), does it look good to you?

[yardenshoham]

Yes, go ahead

[silverwind]

I wouldn't mind if we ship a default, unopinionated pack of icons that can be turned off via an option. Requiring extra configuration and especially defining a plugin interface for icons seems too much work and it would probably not see much adoption by the community I guess.

[yardenshoham]

That is to say, the approach in this PR was good enough?

[lunny]

I wouldn't mind if we ship a default, unopinionated pack of icons that can be turned off via an option. Requiring extra configuration and especially defining a plugin interface for icons seems too much work and it would probably not see much adoption by the community I guess.

But if users could put their icons on custom/, it could be part of the theme which is attractive.

[yardenshoham]

Still, having the material icons by default would look good to most people that need no customization

[silverwind]

I can accept this PR. I do not see icons as part of the theme, but if we can make them overridable via custom folder, it's a nice bonus.

I wouldn't expect any community themer to keep up with this task. Assuming we are going to frequently update the icons, it will be a herculean task to keep a custom icon set in sync with our base, which if it is the material one, seems to add new icons every week.

[yardenshoham]

I'm not gonna reopen because I think the majority will block

[silverwind]

I like the "icon pack" idea. Add files with the name cpp.svg or something in a directory and afterwards .cpp files get that icon. By default that folder is empty which results in the default icon. Then everyone can add the desired icons or keep it empty. This wouldn't bloat compiled Gitea too.

It won't be so simple in many other cases where regex match is needed. That is one of the reasons why I don't see this as suitable for themeing.

I don't see it as bloating, I see it as a nice optional enhancement to the UI. What is the total file size of the icons?

[wxiaoguang]

I am trying to implement a "custom" approach based on yardenshoham's solution.

Let's see if my proposal could work. If I my proposal has problems, let's continue here.

[KN4CK3R]

The icon pack could contain similar logic as this PR and adding the icons is the "enable" flag.

[yardenshoham]

What is the total file size of the icons?

2.8M    node_modules/material-icon-theme/icons
160K    assets/material-icons.json

[delvh]

It won't be so simple in many other cases where regex match is needed

That hasn't even been implemented with the approach proposed in this PR, so I don't see a reason to support it at all.
How often does it happen that you actually need a regex to describe which files it applies to?
The only one that comes to mind is ya?ml.
And that simply needs the same icon for the two different values.

[yardenshoham]

I'm sure that the material theme is good enough for 80%+ of users and if not, it can be disabled...

[silverwind]

It won't be so simple in many other cases where regex match is needed

That hasn't even been implemented with the approach proposed in this PR, so I don't see a reason to support it at all. How often does it happen that you actually need a regex to describe which files it applies to? The only one that comes to mind is ya?ml. And that simply needs the same icon for the two different values.

I hadn't checked in detail how the matching worked (because the diff view is so slow), but it didn't seem like a simple "endsWith" check at first glance, but maybe it actually is.