QColor("red") is drawn as blue ?

SPlatten

I am using a Qt 4.8 and QMap to store colours:

typedef QMap<QString, QColor> tFaultsMap;

In my class:

private:
    tFaultsMap mmpFaults;

Inserting an entry into the map:

mmpFaults.insert(strTabKey, QColor("red"));

When the tab is painted I can see that the tab is draw with a blue background not red, I have encountered this before where the red and blue components are swapped around, how can I fix this?

This is running on a version of Linux developed inhouse, this issue seems only apparent when getting retrieving the colour from the map.

SPlatten

@JonB , it is an apparent bug in Qt, probably just this version of Qt, I have now fixed it by swapping around red and blue. When the QColor is created by passing "red", all is good and the name returns #ff000.

The problem comes when storing the colour in the QMap when extracting it from the map, the name then returns #0000ff.

I've fixed this by doing the following after taking the colour from the map:

QColor color(citFound->value());
const int cintBlue(color.blue());
const int cintRed(color.red());
color.setBlue(cintRed);
color.setRed(cintBlue);

The displayed colour is now correct and name returns #ff0000.

JonB

@SPlatten
It seems extremely unlikely that QColor("red") could return the red color normally but miraculously return the blue color when stored in or retrieved from a QMap. Unless you can find a bug report to that effect (which I doubt) I would look elsewhere for your issue (e.g. maybe you overwrite that key entry's value later, or it's not used correctly on the tab and that defaults to blue). You could also try with QColor(Qt::red). It's easy enough for you to set this up in a test case, and of course remove the "tab drawing" from the equation....

SPlatten

@JonB , it is an apparent bug in Qt, probably just this version of Qt, I have now fixed it by swapping around red and blue. When the QColor is created by passing "red", all is good and the name returns #ff000.

The problem comes when storing the colour in the QMap when extracting it from the map, the name then returns #0000ff.

I've fixed this by doing the following after taking the colour from the map:

QColor color(citFound->value());
const int cintBlue(color.blue());
const int cintRed(color.red());
color.setBlue(cintRed);
color.setRed(cintBlue);

The displayed colour is now correct and name returns #ff0000.

VRonin

@SPlatten said in QColor("red") is drawn as blue ?:

The problem comes when storing the colour in the QMap when extracting it from the map

It can't be. it just can't

JonB

@SPlatten
So far as I know QMap does not have any particular code for a QColor as the value, it's just a templated for a generic T. So you are saying:

QColor c = QColor("red");
qDebug() << c;

works, but

QColor c = QColor("red");
qDebug() << c;
map.insert("red", c);
qDebug() << map["red"];

shows a different value for the two qDebug()s, right?

Maybe QMap is broken in 4.8, nobody else noticed but you'd better remove all QMaps from your code if it's broken like that it's too dangerous to use.

SPlatten

@JonB , sorry, I haven't got the time right now to try your code, but what I posted in my last post is exactly what I've observed. After googling this issue before trying to fix it, its not new, others have reported it before, I don't expect this is a problem in later releases of Qt, probably just a but in the 4.8 release?

SPlatten

@VRonin , try it with 4.8, I wouldn't expect it to be an issue in current releases. Its a big endian / little endian problem, so its also OS / hardware dependant.

JonB

@SPlatten said in QColor("red") is drawn as blue ?:

After googling this issue before trying to fix it, its not new, others have reported it before

Got it. I tried Googling qt4 qmap qcolor but got nothing relevant. Could you just provide a link to whatever else has the same problem, will only take you a second, thanks.

SPlatten

@JonB , try this:
https://www.google.co.uk/search?q=qt+red+and+blue+swapped&ei=4Hm9YvjzJ_WgptQPkJG3qA8&ved=0ahUKEwj449Dn-tT4AhV1kIkEHZDIDfUQ4dUDCBk&uact=5&oq=qt+red+and+blue+swapped&gs_lcp=Cgdnd3Mtd2l6EAMyBQghEKABMgUIIRCgATIFCCEQoAE6BwgAEEcQsAM6BQgAEJECOgQIABBDOgQILhBDOgUIABCABDoFCAAQkgM6BwgAELEDEEM6CAgAEIAEELEDOgcIABDJAxBDOgYIABAeEBY6CQgAEB4QyQMQFjoICAAQHhAWEAo6BwghEAoQoAE6BAghEBU6CAghEB4QFhAdOgoIIRAeEA8QFhAdSgQIQRgASgQIRhgAUNgQWIc1YKw2aAJwAHgAgAHWAYgBphSSAQcxMC4xMi4xmAEAoAEByAEIwAEB&sclient=gws-wiz&safe=active&ssui=on

JonB

@SPlatten
Thanks. Nothing from that mentions QMap anywhere, more device/driver-specific stuff. But have to respect your finding! Very, very odd that QMap could be at issue even if there is indeed a red/blue problem in some circumstances.

It's not possible that your issue is a driver or whatever, where you have to do the swap, but not actually related to QMap?

JonB

@SPlatten
I thought about this. The only thing QMap should be doing is using the QColor copy constructor to store the value (correct me if I'm wrong). Which would imply that has got it wrong. Which ought to mean (I believe)

QColor("red") != QColor(QColor("red"))

? In which case be very careful about copying colors anywhere?!