Naming the root directory where radiant.exe is; "bin", will cause icons to not work

[CansecoDev]

So yeah, I hit the 0.1% use case lottery, it's just with bin, it will only trigger the issue by naming the root directory bin.

Naming the root directory where radiant.exe anything else thanbinsolves this issue.

Seems to be related to #17

The libgdk_pixbuf bundled with the latest release 20210105-win64 is 2.40.0, while newer, it doesn't seems to work producing the "no icon graphics" bug.

A workaround that seems to work is to take the libgdk_pixbuf bundled with 20200514-win64 that is 2.32.1.0 and replace the other with this.

I propose a new hotfix package (with the older libgdk_pixbuf) to be released as a temporal solution to this issue before the next release, just to prevent confusion.

It would be good to look into why a newer version of libgdk_pixbuf is not working properly, then as a real fix for this.

[Garux]

The problem is, 20210105-win64 works for everyone else 🤨 Do you have netradiant-custom-20210105\lib\gdk-pixbuf-2.0\2.10.0\loaders\libpixbufloader-png.dll? This is extenral module, used by pixbuf. Older mentioned pixbuf does not use such external modules.

[CansecoDev]

So, now this is odd. I found what is causing the issue;

Instead of running radiant.exe from it's default directory, I moved the whole content of netradiant-custom-20210105 to a bin directory I made somewhere for it, that's how to reproduce this issue.

• Get the 20210105-win64 package.
• Extract it.
• Rename netradiant-custom-20210105 to something else (like bin).
• Run radiant.exe.

Weird that replacing libgdk_pixbuf for an older one worked.

[CansecoDev]

So yeah, I hit the 0.1% use case lottery, it's just with bin, it will only trigger the issue by naming the root directory bin.

[Garux]

After some testing it appears that this is hardcoded case in Gtk. It looks for the stuff in ../, when executed from bin/ folder.