Matthias Melcher schrieb:
[STR Closed w/Resolution]Fixed in Subversion repository. I increased the minimal required contrast to 96. I also increased the weight of the blue component in the luminosity calculations. I will have a test run on MS Windows now, but I believe that this should give better results in all cases.
Sorry for the late response, but ... The modification of the formula _increased_ the luminosity value by two, and therefore the problem does still exist in my environment with the default WinXP selection color. Though I patched my FLTK sources, I'd suggest to increase the required contrast once more to 99, before releasing 1.1.8. Will there be one or more release candidates ? FWIW: my WinXP selection color is (R,G,B)=(49,106,197), luminosity=98. You can easily "see" the default color by using test/input.exe and clicking on the selection color to start the color chooser. Albrecht p.s.: :-) Congratulation ! :-) ZERO active STR's for FLTK 1.1 ! p.p.s.: I'm very sorry, but I just saw that I can also reproduce the "window doesn't (re)draw correctly" issue that someone wrote about recently. Test case: start test/input, start the color chooser, and then move _another_ application's window over the two windows of the test input windows. This leaves strange artefacts on both input windows. A window of another application, however redraws correctly. If I move the modal color chooser window over the normal input window, then everything redraws fine. I tried to reduce the graphic acceleration, but without success. I'll append a (25 KB) png image. You can see the buttons in the lower left part are drawn okay. I first moved another window over both windows, and then the modal window over the lower part of the main window. Should I file another STR ???
<<inline: redraw-problem.png>>
_______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
