This should probably be back-ported

I feel like one should rather fixFormTabWidget.__init__ to support emptydata lists (and do nothing in that case) andto_qcolor (at least let it throw an exception if it can't convert the color, mapping everything to black is clearly wrong).

The color stuff is a bit excessive, but the reason it is the way it is is thatto_qcolor is used as part of the processing of converting user input -> color in the gui which comes back as a string. The commit message on the last time thecolor = str(color) line was touched references dealing withQString issues which is a nasty bit of API change over in pyqt. Having this default to black isn't a bad course of action if the user types 'aardvark' into the color box and it looks like we are relying on Qt default behavior here to get that, not ours. Making sure we pass the initial color in in an unambiguous string like way is relatively clean and the minimal change to fix this problem. I think any other way would be a change in behavior and require a good bit of re-working on the Qt side of this.

Same withFormTabWidget, ensuring mpl passes in valid input is simpler than modifying the Qt code.

formlayout.py is an external project that we bundle so I am biased against modifying it more than absolutely needed.

@anntzer If you would like to propose more invasive changes PRs are always welcome, but I think that these changes fix the problem in a relatively clean way.

Roughly related to#4304 which also involves this widget and colors.