I have gotten this failure consistently for some
Linux 2.4.18, JDK 1.4.0_04, CVS trunk,
full-build-linux.sh (testedmodule=openide) in a
Created attachment 11725 [details]
Still consistently failing for me in dev builds, BTW.
I believe it's fixed in the proppanel_rewrite branch, which will
hopefully be merged in the next week or so.
I'm wondering if it's a platform-specific thing, tho - it's
occasionally but very rarely failed for me on Windows.
Note: I have been running in a nested VNC server with an 8-bit
display. Quite possible it does not fail when run on a 16-bit display.
TBD. If so, do we really want a unit test which passes or fails
depending on the bitplanes of the graphics display?!
Ugh...I just committed another test which does the same.
Honestly, I don't have a clue how to avoid this problem - for some
things, you simply need the pixels. It's conceivably avoidable for
this test; for the one I just committed, it is checking whether the
error icon is displayed for marked properties, or ones that specify
their own icon to display. I can't see how to test that that hasn't
gotten mangled without asking the component to paint itself, and
at any point along the way an image can get converted into one
compatible with the display.
I could just write in a test if the graphics environment is 8 bit,
and just not try to run this stuff if that's the case. As long as
the automated tests are not running in an 8 bit environment, that
This is fixed on the property panel rewrite branch - tests such as
this are no longer run in inappropriate graphics environments.
Property panel rewrite branch merged.