[Feature] Show matching icons based on the file type

[UnlimitedCookies]

Hi! It would make it much easier to be able to visually identify and distinguish files according to their file type. The current icon looks a little dull (and boring) imo.

This should cover various file types. e.g. images should have an image icon and so on..

This is how it currently looks like: Here there should be a little icon for .go and a shell scrip icon for the .sh file respectively.

[SuperSandro2000]

It would be really great if this icon pack (https://github.com/vscode-icons/vscode-icons) for VSCode would be an option.

[a1012112796]

I think we can do it by update gitMaster which has support it in gh https://github.com/ineo6/git-master

[UnlimitedCookies]

@SuperSandro2000 I would actually prefer something flat e. g.: https://github.com/PKief/vscode-material-icon-theme

Maybe we should choose something even more minimal.

[a1012112796]

https://github.com/ineo6/file-icons

[SuperSandro2000]

I think we can do it by update gitMaster which has support it in gh ineo6/git-master

I already use GitHub Refined and they have overlapping feature sets which could cause issues.

[hendrikbl]

I have no experience with go but I quickly made a vue component using file-icons-js.

That is propably not the best solution since there is a delay between rendering the page and rendering the icons. I guess that's because of the way the template engine works.

The best solution would be to write a wrapper for file-icons in go, but that would be a lot of work.

Anyways, here is my attempt: https://github.com/hendrikbl/gitea/commit/feb273fbb817f4e156dd1ff8f5eb36b120ba8680

[OdinVex]

Perhaps allowing us to specify icons such as by /icons/theme/extension, et cetera. Some people might like official icons per file-type, some might like to use other public themes such as Papirus (I'd recommended as an alternative). Edit: At the very least, icons for files that are particularly useful for Git/Gitea, such as .md, images, common document types (odt, txt, et cetera), git files...

[yardenshoham]

Two PRs have been opened to implement this and were rejected. I think it's safe to say this proposal is rejected. For anyone that wants this, https://github.com/Claudiohbsantos/github-material-icons-extension looks nice

[OdinVex]

No worries, more people'll just keep creating Issues in the future hoping for the same thing, so eventually it'll make it into Gitea or Forgejo or whatever else people move on to.

[yardenshoham]

@go-gitea/technical-oversight-committee please reopen if this proposal is accepted

[delvh]

IIRC, the problem was twofold:

1. It was "too colorful" for some people (so they wanted it as a user setting instead of a global setting)
2. It was not configurable enough, meaning that people had no choice apart from enabling or disabling it

The gist of this is for me it will be accepted if the icons can be configured, i.e. by supplying a directory containing icon files and we fallback to the normal file icon when no matching icon has been found.

Our job would then simply be maintaining a directory with default file icons (which we can offload into another repo).

[OdinVex]

1. It was "too colorful" for some people (so they wanted it as a user setting instead of a global setting)

Per-user would be easy to implement...just as easily as a single 'global default' preference (enabled and symbolic/non).

2. It was not configurable enough, meaning that people had no choice apart from enabling or disabling it

Simple to configure, global default preference for showing, user-preference for override (enabled and symbolic/non), global URI for admin-controlled icon repo with a simple icon config for extensions supported (with default fallbacks).

Icons from Papirus theme are extremely popular. Rather permissive license, too, GPL-3.

If only browsers could allow for local-icons to be used for an extension.

[wxiaoguang]

I won't say it is rejected. There are just some disagreements about how to manage the hundreds of icons, there is no conclusion from TOC yet.

[OdinVex]

I'd say let admins provide a custom override and let admins override any extension by simply providing a file named with the extension. If you leave it to the admins it lessens this decision. Those that don't want it can turn it off and those that do can enable it. Maybe only by default do this for git-related icons (.gitignore, etc)...leave it to the admin to determine if they wish behind the scenes to grab papirus or something and manage from custom overriding. I think doing it for at least git-related files and maybe even Gitea-related (workflow-folders maybe?) would be more than reasonable enough for Gitea to manage. Everyone's happy then, I think. Very low burden for Gitea management, admins can completely control it all, users themselves can turn on/off for their viewing. I'd recommend symbolic (less colorful) and regular icons. Preference order: admin (on/off, both types/single type), user (on/off, both types/single type). Maybe even icon themes. Some people like materia/material icons, I'm no fan but I'd take'em for missing icons. Some like symbolic, I do. Papirus is often used by projects, it's a huuuuge project managed by its own team and I like their icons too. *shrug* Just thoughts.

[lunny]

We may need to extern the theme concept. Those icons will be a part of the theme and could be downloaded from an external git repository or tarball. At least, including the amount of icon files in the codebase and keeping it updated wasn't considered maintainable.

[OdinVex]

I don't think they should be a part of the theme, it'd take away from customization. I don't like glossy icons at all, I prefer a flat and/or symbolic type...but I do like the default theme in general. We'd end up with many 'Gitea' theme with 'X icon pack' if we tied it to themes. Theme selection and icon selection.