|
From: John M M. <jo...@sm...> - 2004-08-31 18:17:34
|
This is fixed, I've released an early VM for testing of application background click behavior and the color mapping change, we now use a lookup table to smoothly map from '00000'b<->'11111'b to 0x00 0xFF I most likely will backport this change to a 3.7.5 version in the next week. You can find a beta on see http://homepage.mac.com/johnmci/ Squeak 3.8.1Beta2.app.sit It has a) Native Menubar support, still being written is the Smalltalk EventSensor code (my task for today). b) The color mapping from 16 color space to 32 bit color space follows a smooth transition curve, versus a logrithmic like pattern. This makes color shading look correct when going from 16 to 32bit displays and having squeak in 16bit appearance mode. c) Multiple window support, (a work in progress by Tim and myself). d) Minor changes to mac support files to eliminate compiler warning messages about improper casting, and returning void from routines returning int. e) toss the mouse click activation event when you click on the Squeak window and it's a background window. On Aug 31, 2004, at 2:39 AM, Bert Freudenberg wrote: > Hi John, > > when testing the new Squeakland image > (http://impara.de/drop/m17n/DSqueak3.8a-5976-60004-267r-plugin.zip), I > noticed the menus look odd. They now have a horizontal gradient, which > before was a solid color. Apparently, a gamma correction is performed > when displaying the 16 bit Squeak Display on the OS's 32 bit screen. > Things look fine when both the OS and Squeak are set to 16 bits. Is it > possible to suppress this color correction? We cannot easily change > the default depth of Squeak to 32 bits, because certain existing Etoys > rely on exact color matches. > > - Bert - > > > -- ======================================================================== === John M. McIntosh <jo...@sm...> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |