feat: add file and color controller setting types

[acolombier]

Add new controller setting type, particularly useful for screen mapping.

Screencast.from.19-09-24.10.02.23.mp4

TODO:

• Unit test
• Improved UI

[JoergAtGithub]

These setting types are great features!

For the file selector I would expect a widget like this:

and a XML settings for the allowed file types.

More complicated might be a generic definiton for colors, as:

• we have already certain purpose specific colormaps:
  
• but more important here, many controllers have only a small list of supported colors, as this list of named colors:

  mixxx/res/controllers/Traktor-Kontrol-S3-hid-scripts.js

  Lines 149 to 171 in 067792b

  	// The S3 has a set of predefined colors for many buttons. They are not
  	// mapped by RGB, but 16 colors, each with 4 levels of brightness, plus
  	// white.
  	this.hid.LEDColors = {
  	OFF: 0x00,
  	RED: 0x04,
  	CARROT: 0x08,
  	ORANGE: 0x0C,
  	HONEY: 0x10,
  	YELLOW: 0x14,
  	LIME: 0x18,
  	GREEN: 0x1C,
  	AQUA: 0x20,
  	CELESTE: 0x24,
  	SKY: 0x28,
  	BLUE: 0x2C,
  	PURPLE: 0x30,
  	FUCHSIA: 0x34,
  	MAGENTA: 0x38,
  	AZALEA: 0x3C,
  	SALMON: 0x40,
  	WHITE: 0x44
  	};

• our current color mapper API has no link to the XML yet: https://github.com/mixxxdj/mixxx/blob/main/res/controllers/color-mapper-api.d.ts
• Maybe we need a solution to define a color map from XML instead of JavaScript?

[acolombier]

Thanks for the early feedback!

For the file selector I would expect a widget like this:

Yes, that makes sense. It's in the todo list already :)

we have already certain purpose specific colormaps:

The current widget are more tailored for palette AFAIK, not unique colour selection, so not sure how to do this? I was thinking of adding a color indication inside/next to the pick button

but more important here, many controllers have only a small list of supported colors, as this list of named colors:

Yes, this usecase is already covered with enum, and actually used by the S4Mk3. One bits of improvement could be to add some color indication in the dropdown, I guess we could easily add an attribute on the option element if we wanted to improve the UX for those?

[Swiftb0y]

I think using the Qt color picker is fine. If we want to we can pre-fill their color with for example the users currently track-color palette (the palette source could also be configured as part of the setting). But lets KISS for now until we have a good reason to couple this to our palettes. A palette selector could be interesting indeed, but that is separate from the color picker.

[acolombier]

I have reworked slightly the widget, let me know what you think of it.

(Using the vertical orientation and the horizontal one)

[acolombier]

As suggested by @JoergAtGithub , I've also added the ability to add a color icon next to a dropdown menu, which may be used for color selection.

[acolombier]

All cleaned up now!

[Swiftb0y]

couple more comments. this is getting pretty close to the finishing line though.

[Swiftb0y]

The main issue right now is that there is a lot of repetitive boilerplate needed in the widgets. I'd really like to see a future PR that cleans that up instead of having to repeat the same logic over and over again.

[acolombier]

Thanks for looking into this @Swiftb0y !

there is a lot of repetitive boilerplate needed in the widgets.

What part do you mean? I guess the design of these dynamic setting was meant to come with boilerplate, so we can add various type overtime. Do you have a specific example of section you don't like and you would like to see improved, as well as how?

[Swiftb0y]

well, for example each type essentially has a m_savedValue, m_defaultValue, m_editedValue and reimplements the matching logic save(), reset(), isDirty(), isDefault() again and again. This makes it easy to create inconsistent behavior between different widgets, makes it more complicated to implement new widgets and obstructs the parts which actually are unique between these widgets/types. I feel like this could be solved fairly easily by creating a base class template. Then you could have class FilePickerWidget : public SingleValuedBase<QFileInfo> and that class gives you the basic members you need. You can still do something more costum by not inheriting from that base class, but at least know you don't need to copy and paste the common boilerplate.

[Swiftb0y]

As long as we make sure we don't go overboard with this and create a 5 level deep inheritance hierarchy this should probably a reasonably okay use of inheritance.

[acolombier]

Makes sense - I will look into that next!

[acolombier]

@Swiftb0y is that what you have in mind for the refactor?

[Swiftb0y]

basically yes. Wdyt about it?

[acolombier]

Yeah, that looks good to me, since it does remove boilerplate and duplicated logic. Is this still okay to have this as a separate PR?

[Swiftb0y]

sure

[Swiftb0y]

LGTM as soon as we fixed the MSVC issue

[Swiftb0y]

LGTM. Please squash the fixups

[acolombier]

Done!