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.

[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.

[rubiefawn]

Summary from the Discord, regarding Apple's style guidelines

The icons currently don't follow Apple's style guidelines at all. Unfortunately, adjusting the icon to comply causes problems with the other platforms; Apple wants a drop shadow and baked-in padding, which doesn't work for the other platforms and doesn't play nice at small resolutions.

There are a couple solutions to this:

1. Have separate assets for non-macOS platforms that has no padding or drop shadow
2. Have the build script hide the drop shadow object and adjust the viewBox to remove the baked-in padding when rendering assets for non-macOS platforms
3. Do nothing

I lean towards option 1 since it's not that hard and I can make both versions of the assets, but opinions are welcome.

Here's what the icons would look like on macOS, including padding and drop shadow. These use the same hue as the current assets, but the value gradient is experimental, so no comments on that please.

[tresf]

1. Have separate assets for non-macOS platforms that has no padding or drop shadow
   I lean towards option 1

Agreed. New asset lmms-apple.svg added to data/scalable, mac script updated to use this for the app bundle. Please feel free to update it with the new asset when ready.

[rubiefawn]

Turns out the original lmms.svg already had some baked-in padding, so that can be taken advantage of to allow the drop shadow to be present on all platforms at all sizes.

For reference, here are the colors I used for the macOS icons. The hues are based off of the default theme color palette and the existing assets in this PR. The dark colors are generally 60% luminance and the bright 69%, with the saturation more or less maxed out (in sRGB) for the given hue and luminance.

• 💚 Green (hue 152):
  • Lighter: oklch(0.76 0.2 152) -> #00d36d
  • Light: oklch(0.69 0.18 152) -> #09b960
  • Dark: oklch(0.6 0.16 152) -> #009a4d
• 💙 Blue (hue 250):
  • Lighter: oklch(0.76 0.13 250) -> #6db6ff
  • Light: oklch(0.69 0.18 250) -> #289fff
  • Dark: oklch(0.6 0.17 250) -> #0083e0
• 💜 Purple (hue 288):
  • Lighter: oklch(0.76 0.13 288) -> #ada3ff
  • Light: oklch(0.69 0.18 288) -> #9884ff
  • Dark: oklch(0.6 0.23 288) -> #805bfe
• 💛 Yellow (hue 75):
  • Lighter: oklch(0.87 0.12 75) -> #ffc976
  • Light: oklch(0.8 0.17 75) -> #fcab00
  • Dark: oklch(0.7 0.15 75) -> #d48e00
  • Yellow is brighter overall and breaks the luma pattern a bit (70% to 79%)
• ❤️ Red (hue 21, currently unused):
  • Lighter: oklch(0.71 0.18 21) -> #fe6b6f
  • Light: oklch(0.67 0.22 21) -> #ff4757
  • Dark: oklch(0.6 0.24 21) -> #ee043b
  • Red also breaks the luma pattern a little bit, otherwise the gradient looks too obvious (60% to 67%)

[Mr-Emoticon63]

hey @tresf could you try and resolve those conflicts we got going on in this pr?

[tresf]

hey @tresf could you try and resolve those conflicts we got going on in this pr?

Eventually. Since the artwork changed, I've realized the need to offer a way to do this programmatically, which requires a refactor. I'm not sure when I'll jump back into this as IRL things keep taking precedence.

[Mr-Emoticon63]

hey @tresf could you try and resolve those conflicts we got going on in this pr?

Eventually. Since the artwork changed, I've realized the need to offer a way to do this programmatically, which requires a refactor. I'm not sure when I'll jump back into this as IRL things keep taking precedence.

oh ok