Conversion functions for RgbColor

[uklotzde]

Add reusable functions for formatting colors as strings.

The tests verify that an optional/invalid color produces an empty null string which is not the case for QColor().name().

Update:

• Conversion functions from/to various Qt types: QRgb = RgbColor::code_t, QQColor, QString, QVariant (QRgb, QColor, QString)
• Conversion functions for control values (double)

[uklotzde]

Anything else to do? Because these extensions will be needed for the cue color work.

[uklotzde]

@Holzhaus Switching the typedef of the internal code from quint32 to QRgb will hopefully improve compatibility with Qt code.

[uklotzde]

To avoid spreading the control value conversions all over the place I have added the required functions and tests. Not sure about the placement and naming of the corresponding header file, but this can easily be adjusted later as needed.

[Holzhaus]

Builds find and tests pass. Waiting for CI builds.

[Holzhaus]

Why the typedef? Is this supposed to replace all occurrences of double for CO signals/slots? If not I'd remove this and and rename the functions below to doubleFromRgbColor, because this would be confusing IMHO.

[uklotzde]

No, you don't need to use it.

I was aiming for clean code, at least within this header file. Hard-coding primitive types into the domain layer is usually not desirable. Type aliases don't provide any type safety, so this is just a zero-cost semantic abstraction on the source code level.

But if it is confusing in contrast to the large amount of legacy code I will remove it.

[uklotzde]

These are not arbitrary double values, they have a special semantic in the context of control values. The standalone function name doubleFromRgbColor() is therefore slightly misleading. But if it is invoked as control::doubleFromRgbColor() the correlation might be obvious enough.

[uklotzde]

@Holzhaus Ready

[Holzhaus]

Thank you. Very handy indeed. Code looks good and tests pass. LGTM.

[Holzhaus]

CI builds pass, I'll merge this.