> No, the API must guarantee to support the same charsets on all platforms and builds of Mixxx.
That'll limit us to a somewhat small common subset though. Is that a price we're willing to pay? D...
Hey funny thing. I never have ran into this issue before. I've ran dual monitors for over a decade at work and home. So there are applications that are written in a way (most of them) that do not r...
> Should I expose `QStringConverter::availableCodecs()`/`QTextCodec::availableCodecs()` to JS too, so that developers can chek what is available on their environment?
No, the API must guarantee ...
The `engine` class is already there, and used for nearly every function in the mapping API other than raw IO. There is no overhead, just a different existing class.
Every Mixxx installation must support each mapping. The mapping API must be stable accross installations. There is no problem, to add a long list of charsets to the positive list.
Should I expose `QStringConverter::availableCodecs()`/`QTextCodec::availableCodecs() to JS too, so that developers can chek what is available on their environment?
I think it makes sense since this is computing data that it supposed to be send through midi. Isn't it adding complexity to add yet another interface in the global object; in particular an interfac...
Meh. I'm not in favor of that. The idea is to allow controller developers to use charsets if available without having to open a PR to make it available. I can, however check against `QStringConvert...
> We have in one hand beat maps, where basically everything beat is a \"change marker\". On the other hand we have real \"bar changes\" (Taktwechsel) that would be annotated as a double bar line.
...