Allow custom file icons

[anbraten]

closes #11149

Based on the latest discussions this would be my suggestion for the custom file icons:

• An admin provides icon packs in a data/icons/<my-icon-pack> folder
• Users can select one of the provided icon packs or leave the basic / unstyled one (same way as selecting a template)

Would be interested in feedback before continuing 😊

Sample icons: https://github.com/anbraten/gitea-icons

TODO

• add some sample repo with a prepared icon pack (https://github.com/anbraten/gitea-icons)
• cache icons loaded from fs
• allow user to select an icon pack from a list configured by admin (skipped for now. could be easily added later on if required)

[lunny]

It's better to have a configuration item on app.ini to switch the icon pack.

[lafriks]

Not in this PR but I would prefer to be able to select this as per-user option

[lunny]

I think making icons as new storage is better so that icons can be put in Minio or S3 compatible places and can be cached with CDN or similar tools.

[wxiaoguang]

Actually there are other attempts for this, for example, Add material icons for file list #26236

But there are still no agreements about:

1. How to store these icon files
   • By a binary zip in git repo? Is binary file (hundreds of KBs to a few MBs) good to store in git repo?
   • By a binary zip in git-lfs? Is git-lfs acceptable for Gitae's development? Is git-lfs usable for GitHub's "allow edit by maintainers"?
   • By a lot of small files in git? There will be a lot. Is it good to bloat the codebase too much (600+ files => 800+ files => maybe soon 1000+ files? And the google official material repo has more than 10K src files)
   • Do not store them in Gitea repo, and only make site admin add them manually?
     • Then my PR should be good enough.
2. How to build new icon packs and publish/deliver them?
   • Should we teach end users how to build new icon packs? Or just provide "official" icon packs?
   • Should it use something like "market" or "theme center" to list the icon packs and provide the downloadable packs?

[lunny]

Actually there are other attempts for this, for example, Add material icons for file list #26236

But there are still no agreements about:

1. How to store these icon files
   
   * By a binary zip in git repo? Is binary file (hundreds of KBs to a few MBs) good to store in git repo?
   * By a binary zip in git-lfs? Is git-lfs acceptable for Gitae's development? Is git-lfs usable for GitHub's "allow edit by maintainers"?
   * By a lot of small files in git? There will be a lot. Is it good to bloat the codebase too much (600+ files => 800+ files => maybe soon 1000+ files? And the google official material repo has more than 10K src files)
   * Do not store them in Gitea repo, and only make site admin add them manually?
     
     * Then my PR should be good enough.

2. How to build new icon packs and publish/deliver them?
   
   * Should we teach end users how to build new icon packs? Or just provide "official" icon packs?
   * Should it use something like "market" or "theme center" to list the icon packs and provide the downloadable packs?

Currently, I prefer to put these pack files as standalone files and managed by storage, so that they can be stored in S3 compatible places. I think this could be an experiment feature first. We can provide official icon packs in another repository and CI can publish it to dl.gitea.com so that users can download an archived file and extract it to gitea. Or we can provide a upload file UI in the admin panel, so users can upload them to storage.

[wxiaoguang]

Currently, I prefer to put these pack files as standalone files and managed by storage, so that they can be stored in S3 compatible places. I think this could be an experiment feature first. We can provide official icon packs in another repository and CI can publish it to dl.gitea.com so that users can download an archived file and extract it to gitea. Or we can provide a upload file UI in the admin panel, so users can upload them to storage.

Then I think some maintainers who have infra access should take over Add material icons for file list #26236 and continue there.

[lunny]

Currently, I prefer to put these pack files as standalone files and managed by storage, so that they can be stored in S3 compatible places. I think this could be an experiment feature first. We can provide official icon packs in another repository and CI can publish it to dl.gitea.com so that users can download an archived file and extract it to gitea. Or we can provide a upload file UI in the admin panel, so users can upload them to storage.

Then I think some maintainers who have infra access should take over Add material icons for file list #26236 and continue there.

If you don't mind, I will create a new pull request from #26236

[anbraten]

1. How to store these icon files

IMO definitely not as part of the Gitea repo. Those icon packs are often quite large and update frequently.

2. How to build new icon packs and publish/deliver them?
   Should we teach end users how to build new icon packs? Or just provide "official" icon packs?

The docs should describe how icon packs should be created. Having a reference icon pack would be great as it will easily show the community how to create their own.

Should it use something like "market" or "theme center" to list the icon packs and provide the downloadable packs?

This PR is basically based on #26236 now with the difference of using plain files from a folder which seems to be extremely simple to me. I also thought of using an http proxy for icons. So it would call http://my-sidecar:3000/icons/file_md.svg and return that content.

For shipping I would suggest to start with something simple. Just clone your icon pack into data/icons/... (which would kind of be similar to how templates work right now).

[wxiaoguang]

Then I think some maintainers who have infra access should take over Add material icons for file list #26236 and continue there.

If you don't mind, I will create a new pull request from #26236

Feel free to do.

This PR is basically based on #26236 now with the difference of using plain files from a folder which seems to be extremely simple to me. I also thought of using an http proxy for icons. So it would call http://my-sidecar:3000/icons/file_md.svg and return that content.

It (github.com in code) won't work because:

1. Gitea might be deployed in a private environment without external network access (some customers for "security")
2. In some regions, the "github.com" is blocked.
3. If there is some network lag, the first requests would be horrible slow.

For shipping I would suggest to start with something simple. Just clone your icon pack into data/icons/... (which would kind of be similar to how templates work right now).

Just FYI: Gitea has a messy "path" system (a lot of hacky patches in history). So what you see might not be what it is. Although I have fixed many legacy path problems, I didn't really "break" it to make it correct. An real example: there is a "custom path" for templates and "options(licenses, labels, etc)", and there is a "data path" for user's data (repositories, avatars). In docker, the "custom path" and "data path" is unfortunately mixed together, so you could see "data/templates" and "data/repositories" in the same "data" directory in docker, but that's not true for non-docker installations. So data/icons/... is not "similar to how templates work", there could be different parent directories.

---

Update: and I can see there are some more problems in this PR.

1. The icon detection is not complete, for example: package.json might have a special icon, but this PR only use ".json" icon. Sorry, misread.
2. svg.Normalize is a heavy function, it should not be called for every SVG every time (RenderHTMLFromString)

TBH I think the "icon pack" solution could be continued by #26236 with a separate icon pack file.