Dynamic branding color for different build types

[rubiefawn]

Adds scripts that, if run, change the color of the branding to indicate unstable builds.

• Colors the splash, app icon and project icons: 💚 "STABLE", 💙 "BETA|ALPHA", 💜 "NIGHTLY"
• Brands the installation directory
  • macOS: /Applications/LMMS Nightly, etc
  • Windows: C:\Program Files\LMMS Nightly, etc
• Separates the config files between release types:

  -rw-r--r--     1 owner  staff    1557 Mar  6 04:13 .lmmsrc-nightly.xml
  -rw-r--r--     1 owner  staff    1659 Mar  5 02:21 .lmmsrc.xml
  

Developers notes:

• Brands the splash screen, app icon, project file icon
• Adds new optional build dependencies: rsvg-convert, imagemagick
  • fallback support for inkscape, gimp
• Adds new build option WANT_DYNAMIC_BRANDING (default ON)
• Adds new modules to cmake/modules/branding/

  cmake/modules/branding
  ├── BrandingHelpers.cmake
  ├── BrandingInstall.cmake
  ├── IconUtilConvert.cmake
  ├── MagickConvert.cmake
  ├── SetupBrandingEnv.cmake
  ├── SvgConvert.cmake
  ├── SvgRecolor.cmake
  └── gimp_convert.scm.in
  

• Adds new BRANDING_DEBUG (default OFF) for troubleshooting branding related issues

---

⚠️Todo

• Properly auto-detect build type from git tag (or assume unstable otherwise)
• Provide example screenshots here
• echo message regarding build type & corresponding branding in cmake
• Trigger soft warning when bash and other command-line tools aren't available (Windows compatibility, see issues below)
• Document command-line dependencies

❓ Optional

• Show build type in splash screen
• Show build type in about dialog
• (SKIPPED) Use the svg resources directly in LMMS (would require significant effort, documentation)
• Re-implement the entire concept in cmake to increase cross-platform compatibility (big task)

❌ Issues

• msvc build environment not handled at all. Windows does not have the tools required to render .svg files without some significant setup. .ico files can be produced with gimp from a set of .png images, though. msvc builds will default to the existing default green raster resources. (Fixed with `choco install imagemagick rsvg-convert)

---

Previews (as of 2019-09-15)

This PR was rewritten in 2025. The original code is left available here for historical purposes: https://github.com/tresf/lmms/tree/dynamic-icon-old

[eagles051387]

Hi Guys, Just a suggestion I wouldn’t call the read heart unknown I would call it development or something of the sort that way people know its under development and can have breakages. Regards, Jonathan (Email quote removed by @PhysSong)

[rubiefawn]

Thanks for the input, @eagles051387, but the red will remain "unknown". See below:

What ❤️ UNKNOWN build type IS

• A warning, indicating an immature build that is not ready to use and has zero usability guarantee.
• A fallback, indicating an error somewhere in the version detection script.

What ❤️ UNKNOWN build type IS NOT

• Binary source security
• Used or specified intentionally
• The 💙 BETA Release Candidate option (some new, stable features that need testing)
• The 💛 NIGHTLY Nightly build option (new, unstable features that need testing)
• The 💚 STABLE Stable build option (as stable as it gets)

[tresf]

@eagles051387 your comments are a bit out of context because they were placed in the main discussion (I assume they were in reference to this #5166 (comment) review discussion). I gave it a thumbs down because of your history of lazy replies to complicated problems. Please be more considerate of the way the tracker works (you should know, you helped set it up). <3

[RebeccaDeField]

Alright, I hope this comment helps to sort things out and provide some assistance. Let's recap a few things:

The files needed for this project are?

• The Splash. Is this rendering correctly without problems?
• The Logos. Which we have recently acquired the sources to and working out the details in discord.
• Anything else? Let me know and I will track it down.

A thorough comb over the discord conversation tells me that somehow different people were under different impressions (including me, previously understanding that we were only finalizing the green/yellow options) for the colors so I wanted to address that here to clarity.

This was the original proposal

If the script is able to auto-detect the build type, then the red option can be taken out.

I already had the colors used for LMMS documented in our design elements file, but I have separated it out and added it to the directory on its own so that it is easier to use and find in our artwork repo here. Of course, the green and even the yellow can stay exactly as it is, but I wanted to suggest tweaking the hues of the other colors to match these for consistency.

That would these examples all color variations available if matched exactly to these colors (I'm assuming we would just match to the right hue, but wanted to add everything for clear communication):

And as per Ian's request, here are the hex codes for all of the colors:
Orange: # db9300
Blue: # 0ac8bb
Red: # 800a1d
Purple: # 3c3282

If we do end up using red, I suggest matching to the wine-red already in our palette.

[tresf]

@RebeccaDeField,

@iansannar has given me permission to help with this script to add multiple SVG size support. What I need:

• Optimized SVGs for all Desktop icon resolutions
  ... the ones I have now from @Umcaruje will suffice until the optimized SVGs are provided
• Optimized SVGs for Windows Modern UI tile "UWP"
  ... the ones I have now are OK for proof of concept, but use a color code in the SVG that's off by a hair. I've hand-edited this for now so I can move forward with the script
• Optimized SVG for splash screen
  ... the one we have now isn't rendering in Chrome properly making it hard to test
• Optimized SVG for projects/mimetype
  ... the ones I have now from @Umcaruje will suffice until the optimized SVGs are provided. Why do I need these? Well, we're already batching the desktop icons, so I'm going to add the same .ico|.icns creation for consistency purposes

So pretty much ALL SVGs need to be optimized and redelivered. The build colors should be easy to tweak.

Side note, I feel these colors are too close to be used as versioning identifiers.

Lastly, we'll need to make a decision on number of colors we're doing. I think Discord is the best place for that conversation?

[Umcaruje]

@tresf can you explain what

use a color code in the SVG that's off by a hair.
for the UWP icons means?

I am in the process of making the optimised SVG's, I'll be delivering them to the artwork repo in a pull request

[tresf]

use a color code in the SVG that's off by a hair.

@Umcaruje please take a look at the green hex color used in the Windows 10 tile. It's off slightly when compared to the icon. e.g. #249a57 instead of #249a56

[Umcaruje]

please take a look at the green hex color used in the Windows 10 tile. It's off slightly when compared to the icon. e.g. #249a57 instead of #249a56

That's because it does not use a gradient, and the background is a solid color, though I suppose we could change it if it will simplify the scripts, it's not that big of a shade difference

[tresf]

That's because it does not use a gradient, and the background is a solid color, though I suppose we could change it if it will simplify the scripts, it's not that big of a shade difference

I'm fine either way, but I can't believe with any reasonable belief that this is intentional. The difference between the colors is indistinguishable by the naked eye. It seems unlikely that this was intentional. I don't mind, but if by some chance it is intentional, I'll need blue, yellow, red equivalents. If these aren't provided, the PR will be merged with the ones I've created.

[Umcaruje]

I'm fine either way, but I can't believe with any reasonable belief that this is intentional. The difference between the colors is indistinguishable by the naked eye. It seems unlikely that this was intentional. I don't mind, but if by some chance it is intentional, I'll need blue, yellow, red equivalents. If these aren't provided, the PR will be merged with the ones I've created.

I'll change them to the hex you said

[Umcaruje]

@tresf @iansannar I have pushed the icons in optimized svg format to LMMS/artwork

You can find them in folder Icon & Mimetypes. @RebeccaDeField also uploaded a optimized svg version of the splash screen, which you can find in the folder Default Theme

Let me know if there is any more issues with these files, all your demands should have been met.

[RebeccaDeField]

@tresf

So pretty much ALL SVGs need to be optimized and redelivered.

Done.

Side note, I feel these colors are too close to be used as versioning identifiers. Lastly, we'll need to make a decision on number of colors we're doing. I think Discord is the best place for that conversation?

Will put together some clear options and head up the conversation over on discord as soon as I can.

[PhysSong]

@tresf What are the remaining tasks for this PR? Are there anything that I may help?

[tresf]

@tresf What are the remaining tasks for this PR? Are there anything that I may help?

The TODO is pretty up-to-date. I was hoping to use Gimp as a rendering engine on machines without the standard build tools (e.g. MSVC). This is a pretty esoteric task though... https://superuser.com/a/1545028/443147 (Gimp was chosen because it's a very common Desktop app for Windows developers, but one which can technically pull this off through a batch process)

The other tasks are simply testing and fixing any logical fall throughs (mostly the handling of changing build types between compiles, something that's probably a buggy process anyway).

Edit: Probably worth noting, Microsoft has since dropped the Windows 8-style "tile" icons, so these can probably be pulled from the PR (e.g. cmake/branding/svg/windows-tile_150x150.svg and friends)

[rubiefawn]

Coming back to this after a few years with the hope of actually finishing what I started. I don't know much about cmake, and I think once that got introduced (which was correct) I let responsibility fall on Tres. That wasn't very considerate of me since he has much more important things to worry about than gui colors lmao. I'd like to give this another shot, this time with the intention of actually learning cmake myself.

It looks like in the time since this was last touched, the way Apple builds are handled have been fundamentally changed, Windows 8 tiles have already been dropped, and some headway has been made on using SVG resources directly in LMMS.

I'll post another update once I've read some docs and have any idea what I'm looking at.

[tresf]

• Use the svg resources directly in LMMS (would require significant effort, documentation)

We have this now since #7667. I'm not sure how much this will help this effort.

It looks like in the time since this was last touched, the way Apple builds are handled have been fundamentally changed,

Yes! Our packaging is completely different now and we actually are using Windows for builds now (they'll likely become our default windows installers in the not-so-distant future), so the concerns about tooling on Windows are more valid than ever.

So I think the next step is to cherry-pick the parts of this PR that work, but try to make it more organized so that files like cmake/branding/CMakeLists.txt are a bit easier to understand the flow of. This is mostly on me since it largely involves cmake. I should be able to help with it in the coming days.

[tresf]

Ok, I've made some progress with the refactor...

So far I have three utility classes:

• SvgRecolor - Rebranding the SVGs
• SvgConvert - Convert SVGs to PNG
• IcnsConvert - Convert SVG to Icns (Apple)

What's needed:

• IconConvert (windows icons)
• Decide how to tie it all into the build system (e.g. pick the correct stage of the build process)

I've coded very basic support for inkscape and imagemagick.

WIP here: master...tresf:lmms:dynamic-icon

I'll continue working from this WIP branch and then once viable @rubiefawn, I'll ask to merge back into this PR. This refactor should help make the rest of the cmake logic much easier to navigate.

The code is pretty simple:

include(SvgRecolor)
set(svg_green "#27ab5f;#249a56;#34d07b;opacity=\".1\" fill=\"#fff\"")
set(svg_purple "#5547bd;#493ba1;#7871c5;opacity=\".05\" fill=\"#fff\"")
svg_recolor(svg_green svg_purple "${CMAKE_SOURCE_DIR}/cmake/linux/icons/scalable/apps/lmms.svg" svg_recolored)

include(SvgConvert)
svg_convert("16@2;32;48;64;128" "${svg_recolored}" "icons/%size%x%size%@%mult%/%name%.png")

include(IcnsConvert)
icns_convert("${svg_recolored}" "${CMAKE_CURRENT_BINARY_DIR}/lmms.icns")

Sample output:

Click to expand

--  svg_recolor: /Users/owner/lmms/cmake/linux/icons/scalable/apps/lmms.svg --> /Users/owner/lmms/build/lmms.svg
--  svg_convert: /Users/owner/lmms/build/lmms.svg --> /Users/owner/lmms/build/branding/16x16/lmms.png
--  svg_convert: /Users/owner/lmms/build/lmms.svg --> /Users/owner/lmms/build/branding/16x16@2/lmms.png
--  svg_convert: /Users/owner/lmms/build/lmms.svg --> /Users/owner/lmms/build/branding/32x32/lmms.png
--  svg_convert: /Users/owner/lmms/build/lmms.svg --> /Users/owner/lmms/build/branding/32x32@2/lmms.png
--  svg_convert: /Users/owner/lmms/build/lmms.svg --> /Users/owner/lmms/build/branding/48x48/lmms.png
--  svg_convert: /Users/owner/lmms/build/lmms.svg --> /Users/owner/lmms/build/branding/48x48@2/lmms.png
--  svg_convert: /Users/owner/lmms/build/lmms.svg --> /Users/owner/lmms/build/lmms.iconset/icon_16x16.png
--  svg_convert: /Users/owner/lmms/build/lmms.svg --> /Users/owner/lmms/build/lmms.iconset/[email protected]
--  svg_convert: /Users/owner/lmms/build/lmms.svg --> /Users/owner/lmms/build/lmms.iconset/icon_32x32.png
--  svg_convert: /Users/owner/lmms/build/lmms.svg --> /Users/owner/lmms/build/lmms.iconset/[email protected]
--  svg_convert: /Users/owner/lmms/build/lmms.svg --> /Users/owner/lmms/build/lmms.iconset/icon_64x64.png
--  svg_convert: /Users/owner/lmms/build/lmms.svg --> /Users/owner/lmms/build/lmms.iconset/[email protected]
--  svg_convert: /Users/owner/lmms/build/lmms.svg --> /Users/owner/lmms/build/lmms.iconset/icon_128x128.png
--  svg_convert: /Users/owner/lmms/build/lmms.svg --> /Users/owner/lmms/build/lmms.iconset/[email protected]
--  svg_convert: /Users/owner/lmms/build/lmms.svg --> /Users/owner/lmms/build/lmms.iconset/icon_256x256.png
--  svg_convert: /Users/owner/lmms/build/lmms.svg --> /Users/owner/lmms/build/lmms.iconset/[email protected]
--  svg_convert: /Users/owner/lmms/build/lmms.svg --> /Users/owner/lmms/build/lmms.iconset/icon_512x512.png
--  svg_convert: /Users/owner/lmms/build/lmms.svg --> /Users/owner/lmms/build/lmms.iconset/[email protected]
--  icns_convert: /Users/owner/lmms/build/lmms.svg --> /Users/owner/lmms/build/lmms.icns

[tresf]

WIP updated: master...tresf:lmms:dynamic-icon

Added:

• Windows .ico file generation (new file IcoConvert.cmake MagickConvert.cmake, new function: ico_convert) using magick CLI.
• SVG tool detection (prefers rsvg-convert, will fallback to inkscape, then gimp)
• Gimp support (required a bit of scheme coding, but seems to work for SVG->PNG)
• Started moving some images/icon references in our install steps from ${CMAKE_SOURCE_DIR}" to ${CMAKE_BINARY_DIR} so we're not overwriting our source files
• Moved the code examples into cmake/branding.

Todo:

• I remember one of the issues we had before was the NSIS bitmap, the sizing was hard to get right. That's not coded at all yet. Here is is for reference. We'll have to think about that one; it's not a high priority.
  
• We'll ultimately need to decide where to run the copy tasks. Some items we can copy during packaging, but others are embedded at compile time. We need this to be crystal clear to the developers. For starters, my plan is to get a "purple/nightly" build with hard-coded values, then we can sort out the logic to detect what a nightly actually is.
  

[tresf]

• For starters, my plan is to get a "purple/nightly" build with hard-coded values, then we can sort out the logic to detect what a nightly actually is.

Purple builds for macOS and Linux should be building. Still have to do a bit more refactoring for Windows due to WINRC.

master...tresf:lmms:dynamic-icon

[tresf]

Purple builds for macOS and Linux should be building. Still have to do a bit more refactoring for Windows due to WINRC.

master...tresf:lmms:dynamic-icon

Windows is building now for msvc and mingw. master...tresf:lmms:dynamic-icon

In 2019 this PR was in a struggle when to perform branding (it was at configure time 🤢)

• However, for macOS and Linux, it's most logical between the install phase and the package phase.
• ... but on Windows -- in order for lmms.exe to have the correct artwork -- the branding step MUST occur BEFORE lmms.exe is built (lmms icon and project icon are compiled resources in the exe using an .rc file).

So, with the new branch, I found a strategy that can do both... which is to leverage the same code (cmake/modules/branding/BrandingInstall.cmake) from two completely different phases.

• For macOS and Linux, we use install(CODE ...) and install(SCRIPT ...) using a new macro install_branding
• For Windows, we use add_custom_target(lmms ...) to a COMMAND cmake -P using a new macro add_branded_target.
  (thus allowing us to invoke the same script in two different phases)

How it works:

• To provide the necessary vars, each macro has dynamic variable injection so it's aware of what colors to use (LMMS_BRANDING_COLOR) and where to find original files (LMMS_SOURCE_DIR) and where to place branded files (LMMS_BINARY_DIR)
• Branding now touches the minimal amount of project files needed and should result in a soft failure if the necessary tools are missing.
• As an added benefit, I've learned that .rc file can be provided alongside the .cpp files, so that logic was inadvertently simplified as a result of this feature.

The one item left for parity with this PR is updating the about dialog. After that point, if it's OK with you @rubiefawn I'd like to merge the new branch back into this PR.

[tresf]

Thanks for the OK. Merged my WIP branch back over this one.

Ready for testing and review.

(Old code is backed up incase we need to reference it, PR description updated with link)

[tresf]

Slight enhancements added to this PR:

• LMMS is now named LMMS Nightly, LMMS Alpha in C:\Program Files\ or /Applications/
• .lmmsrc.xml is now named .lmmsrc-nightly.xml, .lmmsrc-alpha.xml
• This is the first time we'll officially "support" multiple installations.

... however for PRs, I've been asked to use LMMS PR#### (e.g. LMMS PR1234), which hasn't been implemented yet.