File System Browser really should have icons for the code-containing files

[hippietrail]

Is your feature request related to a problem? Please describe. When entering a filesystem via import etc we see the "filesystem browser" that lets us choose one file inside a collection such as a Zip archive. The file system browser shows icons for a bunch of file types (based on filename extension) such as images, source code, html, text.

But it only has icons for a couple of code-containing filetypes: .obj and .lib and I suppose .apk and .jar. And the ones for .obj and .lib at least don't really stand out much.

Describe the solution you'd like Since the main thing we reverse engineer with Ghidra is code, it makes sense to include icons for as many as possible: .exe, .dll and .o at least. .com too. Probably a bunch from systems I'm not familiar with.

They don't necessarily all need different icons. They could all share an icon that means "code" or "binary code". There could be one for executables and another for all kinds of libraries and unlinked object code. There could be one for all kinds of dynamic shared libraries, etc.

Or they could all get a Ghidra logo. That would make them stand out from the non-code files.

Or they could use the icon overlay system. There are already overlays for things such as symlinks. There could be one that indicates a file contains code that can be disassembled/decompiled.

Additional context Here's the current icons for .obj and .lib by the way:

default icon for files with unspecified/undetected type .obj .lib

(I don't think filetype icons other than file vs directory are supported by the local disk filesystem browser, which is a different component or maybe just the default Swing component. I didn't look into that.)

[gemesa]

I dont know how it is currently implemented but detecting file types based on their extension is not a good approach IMO, especially on Linux.

ELF files often have no extension:

$ file /usr/bin/ls                 
/usr/bin/ls: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=aeeee2e0bb6f07d85659890089641491b489cd92, for GNU/Linux 3.2.0, stripped

Additionally, version numbers are commonly appended to shared object names:

$ ls /lib64 | grep ^lib | head -n 10
liba52.so.0
liba52.so.0.0.0
libabrt_gui.so.0
libabrt_gui.so.0.0.1
libabrt.so.0
libabrt.so.0.1.0
libabsl_bad_any_cast_impl.so.2401.0.0
libabsl_bad_optional_access.so.2401.0.0
libabsl_bad_variant_access.so.2401.0.0
libabsl_base.so.2401.0.0

https://superuser.com/questions/299009/what-do-the-number-suffixes-in-linux-dynamic-libraries-mean

[hippietrail]

I dont know how it is currently implemented but detecting file types based on their extension is not a good approach IMO, especially on Linux.

Ghidra actually has two methods in its FileSystem code. But both are based on the filename. First it goes by the filename extension, and then it goes by substring. I haven't looked into the substring method yet to see if it currently supports .so. but it's definitely capable of doing so.

I also have a PR in the work that adds a way for FileSystems to provide type info directly rather than using the filename extension.