|
From: Bert F. <be...@im...> - 2004-09-01 13:18:38
|
Great! One more thing I noticed in the NPSqueak VM vs. the regular VM is when you use a 3-button mouse: In the regular VM, the middle and right button bring up the context menu and halo, respectively, so we have a nice red-yellow-blue mapping. There is no difference in fullscreen mode. Running in the browser window, however, the middle button brings up the halo, vs the right button seems to be mapped to ctrl-click. No button brings up the context menu (except for pressing the option key). So we have red-blue-ctrl. When escaping the browser (going fullscreen), the middle button stops functioning at all (no halo anymore). Which means red-nada-ctrl. It would be nice if the behaviour would be the same independent of how the image is started. Also, while you're at it ;-) IMHO a red-blue-yellow mapping would be more consistent with the Finder and other apps, which bring up the context menu on a right click. - Bert - Am 01.09.2004 um 09:40 schrieb John M McIntosh: > I compiled a version Tuesday night. I'll see if I can push it out Wed > evening. > > On Aug 31, 2004, at 2:07 PM, Bert Freudenberg wrote: > >> This looks *much* better! Thanks! >> >> The next Squeakland release is only a few days away, since some >> schools start next week. Michael actually wants to create release >> candidate installers today, with the actual release following later >> this week. Perhaps you could do the backport even sooner? >> >> Btw, I did build a VM myself, but when the latest SF sources only >> have your 3.7.1b3 version? Or is it just the info.plist files and >> resource icons which are not up to date? >> >> - Bert - >> >> Am 31.08.2004 um 20:17 schrieb John M McIntosh: >> >>> 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 - |