Use different app icons for alpha/beta/rc builds (and possibly Mono builds)

[noidexe]

Describe the project you are working on:

Any project not using the latest stable build

Describe the problem or limitation you are having in your project:

When testing alphas, betas, rcs, etc. and having them pinned in the taskbar it's hard to know which is which since they share the same icon

Describe the feature / enhancement and how it helps to overcome the problem or limitation:

Having noticeably different icons for different builds makes it easier to use them in tandem, either when testing alpha/beta/nightly versions

This is what mozilla does with Firefox

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

This is by no means a design proposal, but I think it is important to make them easily distinguishable by shape and color, so they can be identified at a glance and at any size (also for accessibility).

• Anything built from the master branch gets the "master" edition of the icon. This would probably include versions you build yourself, Hugo's nightly builds, etc.
• Officially distributed, alpha, beta, rc and stable versions will use their respective icons

If this enhancement will not be used often, can it be worked around with a few lines of script?:

• If building from source it's just a matter of replacing the icon before building
• For downloaded binaries I think there are tools that can replace the icon, but it'd be very inconvenient to do that every time.

Is there a reason why this should be core and not an add-on in the asset library?:

Can't be done through the asset library

[Xrayez]

The idea is nice. There might be some issue with master and other icons being too different from the current Godot brand/icon. I've used master over the past 3 years exclusively and if I were to stream game development with Godot, people wouldn't really dig into the Godot brand anymore, but on the other hand if we want to encourage people using development builds through curiosity for contributing purposes, that's also a solution.

[Zireael07]

I think we can keep the familiarity with current Godot brand by making either top or bottom part of the logo keep the familiar blue shade in all versions. (I must admit I like the OP's designs a lot) WDYT?

[groud]

I like the idea, though:

• I would not use different icons for the alpha/beta/rc version. One icon for them is enough.
• We should not modify the design too much, the difference must be more subtle.

The main problem is likely implementation-wise, we probably have to add compilation flags to choose the good icon to use. Not sure it is an easy task.

[FeralBytes]

Why not simply interpret the version string with Python, then have all of the icons in a folder in the repository and the script picks the right one and swaps it out as part of the compilation process, just as an early trigger for scons.

I really like the designs, a good first go. But maintaining a similar color on the lower job is probably a good idea.

I do also feel a slightly different icon for alpha, beta, and RC is a good idea, especially if this can be made easy with a script. Because I have had to test between betas and rcs to find out where a change occurred that broke functionality.

[noidexe]

Yeah the mockup was just me having fun with the idea of "building the robot" but it is by no means a design proprosal. I agree that it shouldn't deviate that much from the original logo. I still think the difference should be obvious enough that you don't need to squint to see it and that's why I cited the FF ones. Beta has a very obvious tag and Nightly has a completely different palette. The FF ones are not very accessible to colorblind people though If you actually change the values(i.e brightness/darkness of the color) rather than just shifting the hues, then even if the shape is the same you can get them to be easily distinguishable without reliying on color information

My biggest concern is what @groud mention about implementation details. I didn't include any steps as to how to actually get the feature working since I don't know how the dev team automates builds.

If someone wants a quick and dirty way for their buidls this works: scons_icons.sh

#!/bin/sh

echo -e "Modifying icons..\n==========\n\n"
cp icon.svg icon.svg.bak
sed -e 's/fill:#478cbf/fill:#bf45f5f/g' -e 's/fill:#414042/fill:#ff00ff/g' -e 's/fill:#ffffff/fill:#414042/g'  -e 's/fill:#ff00ff/fill:#ffffff/g' icon.svg.bak > icon.svg
rm icon.svg.bak
inkscape -z icon.svg -e icon.png -w 256 -h 256
inkscape -z icon.svg -e main/app_icon.png -w 128 -h 128
shift
echo -e "\nRunning scons..\n==========\n\n"
scons "$@"
echo -e "\nRestoring icons..\n==========\n\n"
git checkout icon.svg
git checkout icon.png
git checkout main/app_icon.png
echo -e "\nDone"

You can also have all the icon changes in a commit and cherry-pick it or have the icons sets in a separate folder and set it with a script

A set of cppdefines is probably the best option since you can do anything you want that might be conditional to the build being rc, stable, etc such as setting a different window title or a different default theme.

[aaronfranke]

This is by no means a design proposal

But I absolutely adore your designs, they are amazing! Not that I'm opposed to changes.

The main thing I would tweak is that the "RC" text should have a smaller "bubble" around it.

[YeldhamDev]

We could go the GNOME route and add a construction pattern at the bottom. I think it fits quite well:

[bruvzg]

In addition to dev version badge I would also add some badge (or color difference) for the Mono flavored editor (That's what I always do with my local copies).

Edit: macOS Big Sur style variants. SVGs, PNGs and ICNSs: GodotIcons.zip

[Xrayez]

It would be nice if we could customize the icon outselves via SCons build option at least, like scons custom_app_icon=path/to/icon (or through an environment variable like BUILD_ICON_PATH just like you can customize BUILD_NAME currently). This could also benefit the actual game projects which need to override the Godot icon anyway (in case people are already compiling the engine, removes the need to use external programs like rcedit etc.)

[Calinou]

We discussed this proposal in a meeting. We agreed with implementing this feature. The implementation would be as follows:

• The Godot icon remains the same for all build statuses (no color or visual changes).
• A badge is added on top of dev, alpha, beta and RC builds. Each badge has a different color, and possibly different corner radius and position to ease recognition at smaller sizes and without relying on color alone.
• Mono builds will probably not exist anymore in Godot 4.0 (will be replaced by GDExtension, so you can use a standard editor binary and use C#). Therefore, we decided not to implement separate icons for Mono builds at first. A 3.x backport could add icons with a Mono badge if desired.
• SCons would select the icon PNG/ICO set to use at build-time depending on the contents of version.py.

[Zireael07]

Mono builds will probably not exist anymore in Godot 4.0 (will be replaced by GDExtension, so you can use a standard editor binary and use C#).

WHAAAT. This is so seriously awesome! <3 <3 <3

[WhalesState]

This is really awesome, but should also keep in mind that icons usually are rendered in 32x32px, so the text may not be clear on such small size, we can use just a single letter when possible like [ α = Alpha ] [ β = Beta ] [ # = mono ] [ 3 = Godot 3.x ]

64x64

32x32 nearest

32x32 bilinear

[bruvzg]

This is really awesome, but should also keep in mind that icons usually are rendered in 32x32px, so the text may not be clear on such small size

Both macOS and Windows native icons have separate images for every size, so small icons can have a different overlay (e.g., full text for large icons, a single letter for 32x32, and just a badge color without text for 16x16).

[bruvzg]

Both macOS and Windows native icons have separate images for every size, so small icons can have a different overlay (e.g., full text for large icons, a single letter for 32x32, and just a badge color without text for 16x16).

Something like this (open on the separate tab and view at 100% scale):

But it might be better to redraw small icons manually instead of generating from vector, even when exported for the exact size and aligned to the pixel grid it's still blurry.

[AThousandShips]

I think the smaller icons are too busy

[WhalesState]

The text background rect is hiding a large amount of the icon, also Godot terminal icon is drawing the terminal on the bottom right of the icon, try to not make the edits conflict with the terminal icon or hide a large part of the icon to keep the logo clear and also the terminal logo without much changes. that's why i think a single letter is the best choice so we can just keep it on the top left of the icon without changing the terminal icon or hiding a large part of the icon.

maybe X and Y here is a good choice to limit our edits for both the Icon and the terminal icon.

[WhalesState]

Additionally, instead of using white text color to indicate Alpha, Beta, and RC versions, we can utilize traffic light colors for each letter. The letter "α" can be represented in red for Alpha, "β" in yellow for Beta, and "RC" in green for RC. This color-coded approach will enhance clarity, especially when the size of the text is as small as 16x16px.

[bruvzg]

Well, we probably won't be able to add all the info to the icons. I'm not sure what's most important to show, we have:

• .NET / standard variants (do you ever need both? .NET version should work with standard projects).
• dev / alpha / beta / rc / stable (stable + some test version at the same time is common, but I'm not sure if there's much reason to be specific).
• 3.x / 4.x (also likely to exist at the same time, so maybe "LTS" badge for the 3.x?)
• console wrapper (Windows only, icon probably doesn't matter, since it's mostly used from terminal).

[Zireael07]

3.x vs 4.x is the most important distinction at this time (lots of people have a project that's on 3.x still for various reasons while using 4.x for other projects), as well as stable vs non-stable

[WhalesState]

• .NET / standard variants (do you ever need both? .NET version should work with standard projects).

• I don't think the .NET is needed since the users of C# can have GDScript inside and they don't need the other version, also they have said that it will be limited to the 3.x and will be replaced with gdextenstion in 4.x

• dev / alpha / beta / rc / stable (stable + some test version at the same time is common, but I'm not sure if there's much reason to be specific).

• The Dev / Alpha / Beta / RC is so important since most of us downloads them to test the new changes and also inside the bin/ folder they can reduce conflict after building.

• 3.x / 4.x (also likely to exist at the same time, so maybe "LTS" badge for the 3.x?)

• Since the logo is the same and the devs want to keep the old logo without changes, we can only edit the 3.x before the 3.6 stable release, and we keep the 4.x logo the same as the older one, just to prevent conflict for both releases. Additionally, someone may be working on two projects at the same time from two different GitHub repos which use different Godot versions, so they will need to distinguish between the 3.x and 4.x versions, potentially using them simultaneously in certain cases.

• console wrapper (Windows only, icon probably doesn't matter, since it's mostly used from terminal).

• The change for the console icon, for me, is not needed, and it's up to the devs to decide since I usually use the VSCode console or run the Godot executable from the command prompt.

just to make it clear, we may expect the 3.6 stable release soon so we should decide what changes will happen to the 3.6 icon and we wait to see what the devs will say about it or if they ask for more changes.

[justlimeguy]

soo umm, any changes yet?

[AThousandShips]

Please don't bump issues without contributing significant new information. Use the :+1: reaction button on the first post instead.

[tehKaiN]

We discussed this proposal in a meeting. We agreed with implementing this feature. The implementation would be as follows:

* The Godot icon remains the same for all build statuses (no color or visual changes).

* A badge is added on top of dev, alpha, beta and RC builds. Each badge has a different color, and possibly different corner radius and position to ease recognition at smaller sizes and without relying on color alone.

* ~Mono builds will probably not exist anymore in Godot 4.0 (will be replaced by GDExtension, so you can use a standard editor binary and use C#). Therefore, we decided not to implement separate icons for Mono builds at first. A `3.x` backport could add icons with a Mono badge if desired.~

* SCons would select the icon PNG/ICO set to use at build-time depending on the contents of `version.py`.

I'm willing to tackle this.

I've made a quick glance at what the current state of icons is, and apparently each platform has its own icon set (e.g. .ico files for windows, .icns for macos, a couple of .png files scattered across different directories for each DPI grade in android). Also, on windows, there are two icon sets - one for console-spawning executable and one for the plain one.

I'm starting to think that perhaps the best course of action would be to generate all those icons from main logo SVG file to format for each platform, but that would require extra python modules in the build system, namely:

• cairosvg for svg file manipulation, especially conversion to png
• pillow, for further png manipulation, especially saving to .ico / .icns files

This adds extra dependencies for build system - something which wasn't needed for this point and seems to be an overkill for such a trivial task. Still, this would reduce amount of godot logo copies in the repository, and even allow generating the windows console icon variants with the same badge system. The alternative is to not think too much about it and litter the platform data with all required image variants.

Also having compositing system would allow stacking extra ones (e.g. C# until GDExtension thingy is finalized) as well as would be trivial to extend with custom status values (my company uses different status than dev/beta/rc/stable for its internal custom build).

Thoughts?

[Calinou]

I would just commit modified icons to version control so that extra build-time dependencies are not needed. The icons can be made manually or with a script.

[tehKaiN]

Getting there... Yay or nay?

That's 100% python-generated and composed out of SVG files. The console window is also composited with same overlay system. The badge sizes/offsets are easily configurable per badge, per icon size. The 16x16 icons use different build kind SVGs than the rest - that's also adjustable. I also had to expand the windows-specific part of scons system so that a .gen.h file is generated for .rc files so that the proper path to .ico file is supplied.

I took liberty of slightly adjusting the console badge size and offset. Also, the build kind badges are coder assets, so I guess someone with better art sensitivity than me should take a pass through those SVG files. I've borrowed the red color from one of the mockups posted earlier and generated the rest from simple hue adjustment, but I'm not really happy with the lime-green color of RC badge - definitely needs better choice of colors.

It only works on windows part so far, next I'm going to tackle mac and then linux (because I don't know yet how the icons are stored there). Also needs some housekeeping, mainly moving badge svg and py script to misc directory, unless there's better place for it? Also, should I support web/android/ios platforms?

More to come after GodotCon, I guess.

[Calinou]

Also, should I support web/android/ios platforms?

This would be good to support for Android at least, given you can install the editor APK for development releases. It's not essential for the web editor (it could be done in a separate PR), and there is no iOS editor currently.

[bruvzg]

next I'm going to tackle mac and then linux (because I don't know yet how the icons are stored there).

Linux icon can be the same as Windows, there's no specific icon in the repo, it's using the main SVG icon.

macOS icon use ICNS format (can be generated from the set of PNGs), it's in the /misc/dist/macos_tools.app/Contents/Resources, and is a bit different from other platforms since it has a background (you can get templates for background shape from https://developer.apple.com/design/resources/#macos-apps).

[tehKaiN]

I've looked at Production Templates PSD files and there is a license file and it contains the following line:

You may not embed the Apple Design Resources in any software programs or other products.

So I assume I can't just embed plain backgrounds for composing icns, unless I understand that wrong. It's not a deal breaker though, since I can just probably use python's icnsutil package to generate the new icns based on the current/plain one instead of composing it from scratch.

I've been tackling the android thingy so far and I'm halfway there. I think the way it's going to work is that:

• the icons with badge variants will have their dedicated mipmap-mdpi/hdpi/xhdpi folders stored per-badge in respective folders in platform/android/icons
• the current folders with icons residing in platform/android/java/lib/res will be deleted and marked as gitignored
• the scsub will read what release variant is currently set and then copy required icons from platform/android/icons to platform/android/java/lib/res accordingly

I saw that the paths to icons are configurable in one of the cpp files, but I'm not that proficient to judge if I can just generate/change them to anything and the build system will still automagically package them even if they are somewhere else then their current location, so I'm going for this kind of safe option. Or is there a cleaner way to do it?

[tehKaiN]

Ok, looks like I have windows/macos/android stuff working and mostly cleaned up. All the ico/png/icns variants are stored in the repo and they are copied where they are needed during the build as part of the platform-relevant SCsub file.

Linux icon can be the same as Windows, there's no specific icon in the repo, it's using the main SVG icon.

I still don't know how to tackle linux though - I can't find any link between the linux platform and the icon.svg placed in main repo directory. Is the exe+icon bundling step manual? If so, would it suffice if I just provide the svg of icon variants in platform/linux/icons/icon_{build_status}.svg or should I do something more with them?