Add colorized file type icons

[adrium]

I stumbled upon issue #1698. The listing view has made it difficult for me too finding files that are not images, and it inspired me to implement this.

The general approach is to fully define icon rendering in CSS.
Icons are based on the type and file suffix, colors are based on simple definitions, and the palette is from KDE. I tried to include the most relevant types considering modern operating systems, formats, and languages. In the end though, it is subjective what should be considered relevant...

Also related #1256 and #1668.

The colors can be disabled by adding the following css:

#listing i { color: inherit !important }

• requesting to pull a topic/feature/bugfix branch
• pull request against the master branch
• File Browser can be successfully built
• no issues are opened in other repositories
• continuous integration build

Example:

[o1egl]

@adrium well done! Let's wait for community feedback

[adrium]

Thanks for the feedback - glad you like it! I actually got some ideas for slight improvements such as less opacity for hidden files. I will update the code within the next couple of days...

[niubility000]

Is there a way to set this one as a theme? Currently we have "light","dark", maybe we can add this one as a new theme. So users can make their own choice.
Or just let the users to customize their own theme(or skin), including these icons and colors. Then everyone will be satisfied. see here:#1256

[adrium]

The intention is to set the icons and their colors as defaults - like operating systems that provide a default icon theme.
It works well for the light and dark theme. The screenshot is updated in the PR description.

[adrium]

I updated some details:

• Sort definitions by color and alphabet in the stylesheet
• Selected icons are always white
• Hidden and .bak items have less opacity
• Add some more types

[adrium]

Updated with minor last changes:

• CSS selector i instead of .material-icons
• Remove unnecessary :class="type" in <i>

[ramiresviana]

The behavior i expect of files that are not supported by the system is them to be displayed as a blank file icon. FileBrowser has preview only for text, pdf, image, audio and video files, i think that adding specific colors and icons for other file types can lead to confusion.

We could try implementing this gradually and checking the user feedback.

[adrium]

Hi Ramires, thanks for your feedback. I generally like your suggestion of having icons for types that are "supported by the system".

Let's take a closer look:

1. File Browser determines file types based on the go mime module, specifically by file extension. This is afaik how all popular operating systems handle file identification. Only, if the extension is unknown, it tries to detect it from the content.
   However, it depends on the system where File Browser is installed. On my server, the file type of go.mod is application/xml-dtd due to the extension. However, File Browser will still open it as text despite being classified in the broad application/* type. It seems to inspect the file in this case and probably isBinary(buffer) returns false.
   When I run File Browser on my desktop, the same file is audio/x-mod and has a speaker icon because VLC is installed and modifies the file type library. When opening the file in File Browser, a seek bar is displayed and nothing useful can be done with the file which is in fact text.
   File Browser does not handle file identification robustly.

2. Related to the above, if there is a sound.wma file, it is most likely a Windows Audio file. On any Debian based system, this will be recognized as audio/x-ms-wma because of the media-types package. If File Browser is run on Windows, it will also be recognized as an audio file. Again, when opening the file in File Browser, a seek bar is displayed but the file can not be played back because it is not supported by the browser.
   File preview depends on Browser support.

3. Suppose the clicks on a sound.opus file. It can be previewed in File Browser successfully thanks to browser support. However, if you download to file on Windows 10, you can not open it anymore, because there is no application registered for it (as opposed to webp which is opened by Edge). Even if the file can easily be opened in the web UI, it may cause difficulties on the client when downloaded.
   Files can be more difficult to open when downloaded.

There is already much potential for confusion. On the other hand, if File Browser (as per readme a "file managing interface") gives a visual hint of what the file is supposed to be, it helps to manage files - just think of the Downloads folder. It is up to the user to install programs that can handle the files on a desktop. If File Browser is even able to provide a preview - perfect! If it can not, a nice prompt to download the file is displayed - no confusion there.

This why I think icons and colors should be provided independent of preview, by default and without gradual changes.

[jniggemann]

We could try implementing this gradually and checking the user feedback.

I welcome this and think it is a good idea. I've gotten a lot of feedback for the CSS I published in #1256. There are definetly a lot of people out there that want to distinguish files more easily using colorized icons .