Comment 27 for bug 437378

(In reply to comment #12)
> anyway it's not yet "my fault" ;-)
yes it is - you use the wrong toolkit ;-P

> I still don't see why this should be a problem for Qt apps though
X11 is "flat" ie, a "window" is actually only a random X drawable (window type) that's parented by the root window.
Back then, this was no different from the root window children internal structure (ie, "every button was an own X11 drawable" (this has been changed for poor performance on esp. local session)
In other words (and shortened): all windows are part of one mega window (what effectively makes X11 MDI by design - ewww =) and every X drawable inherits settings of the root window - this includes the colormap.
Now, whether X11 or XEmbed are supposed to work across drawables with different colormaps or xv should support ARGB windows or if this is (has been) a bug in Qt, X11 or the drivers - I frankly don't know.
Maybe the Qt window constructor should just ignore/reset colormaps not explicitly set - I don't know either (in fact, I don't know a lot...)

However a client should just not change the "default" colormap, because several other clients may simply not expect this internally (gtk (1.x) -for one- didn't like that at all. Qt cannot apply stylesheets to at least the "window" in ARGB mode, what some applications might rely one, etc....)

Until you figured why gdk does so or gdk gets fixed, you could call

Display *dpy = XOpenDisplay (0);
XDeleteProperty ( dpy, RootWindow (dpy, DefaultScreen (dpy)), XInternAtom ( dpy, "RGB_DEFAULT_MAP", 0) ); // there're probably gdk hooks for the rootwindow/the display - use them.

afterwards - but that's oc only a workaround.