Dynamic branding color for different build types

[rubiefawn]

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

⚠️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
• 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.

---

Previews (as of 2019-09-15)

[tresf]

Some tasks I'd like to add to this PR (feel free to move them to the original description if you wish).

Edited, moved to original post

Before this is merged

• Provide new screenshots of the branding on at least one desktop. This is important so that reviewers like @RebeccaDeField and @Umcaruje can approve the visuals without having to wait for them to have time to build locally.
• Echo a message about the branding in CMake
• Possibly add an official "nightly" word like "Nightly" or "Canary" to the about screen. This may not be easy to automate, but should be investigated.
• Trigger this from CMake and allow a soft warning when the command-line tools (or bash) aren't available. That will allow the build system to chug along as normal in environments like MSVC where bash (or command line tools like rsvg-convert) is normally not available. (it may also be worth investigating migrating these to CMake scripts, which would allow the possibility of MSVC builds to use them).
• This may be the time to find a way to use the SVG logo directly inside Qt so we're not converting (or mismatching) internal resource files (AFAIR, we're not currently using the SVG logo in C++).

After this is merged

• After this is merged, we should document the new command-line dependencies in our wiki. We have dependency lists for many different OSs, all of them should be reviewed for addition of the tools we're using.

[tresf]

I forgot one... add shellcheck scanning of these for common shell script issues although reading the source, I think it's already being scanned, so in that case, check our continuous-integration for any shellcheck failures (I've restarted the job here on Travis and waiting... 🕥)

Edit: Shellcheck is passing so I guess we're OK there. 👍

[PhysSong]

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

Probably not much. You don't need to deal with the Qt SVG module directly to load and render SVG files. The new spectrum analyzer plugin already uses SVG via QPixmap and works fine if the corresponding plugin exists.

[tresf]

svg resources [..] require significant effort

Probably not much.

@PhysSong would your recommend tackling it in this PR? I can switch the splash and icons to use the SVG resources, but I also wonder if it would be better for another PR?

[tresf]

It seems like cmake/branding/CMakeLists.txt mixes tabs and spaces. 🤔

Switched to tabs via 6a49f11 to match other CMake files.

[tresf]

Upon re-review, these should probably be moved back to cmake/branding/CMakeLists.txt. I had thought it was needed due to an order of operations problem, but after re-reviewing, it was more likely a CMake caching issue.

[tresf]

• Show build type in about dialog

Done via 94f742c. TODO . Still need to write Linux files, test various installers.

[PhysSong]

svg resources [..] require significant effort

Probably not much.

@PhysSong would your recommend tackling it in this PR? I can switch the splash and icons to use the SVG resources, but I also wonder if it would be better for another PR?

For what we need to use SVG resources: #5160 (comment)
It adds the Qt SVG library and related plugins as a runtime(not compile-time) dependency. I think we should stick to PNGs until we handle SVGs properly.

[Umcaruje]

What else is needed to be done on this PR?

[tresf]

What else is needed to be done on this PR?

I need to finalize the Linux stuff.

[tresf]

Trigger soft warning when bash and other command-line tools aren't available (Windows compatibility, see issues below)

Any thoughts on writing a fallback for Gimp? Turns out it's completely possible and I figure most MSVC devs would have Gimp installed locally (and perhaps choco install it in AppVeyor?).

[PhysSong]

writing a fallback for Gimp

Sounds good.

[tresf]

writing a fallback for Gimp

Sounds good.

Initial support written in c2a9b42. It still requires some conditional handling, maybe even a wrapper to handle the various tools.

I'm not sure if it will be capable of generating a multi-res .ico file using this technique.

[PhysSong]

@tresf Is this abandoned?

[tresf]

@tresf Is this abandoned?

Not abandoned, just on hold due to personal resource constraints.

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