Folks -
I've just put out a few more updates as summarized below.
Also, we're in the process of trying out the 50-odd that SMA recently assembled, and I'll try to get them out in the next couple of days.
- Dan -------------------------- 2989TfmFixes-ar -- Andreas Raab -- 21 November 2000 Some fixes for transformed grabs and drops."
2990FixPianoKeyboards-di -- Dan Ingalls -- 18 November 2000 Adapts the keyboard to the new event dispatching logic. It was necessary to pass mouse focus from note to note.
2991ParseScript6-tk
2992noSubmorphs-raa -- Bob Arning -- 23 November 2000 - guard a #firstSubmorph with a test for no submorphs"
2993CipherPanelFix -- Dan Ingalls -- 24 November 2000 Fixes a problem introduced by the new Alignment protocols.
2994HandTweaks-ar -- Andreas Raab -- 25 November 2000 Two tweaks for faster hand redraws."
2995mvcWorldFix-raa -- Bob Arning -- 27 November 2000 - guard against premature access of worldState"
2996higherPerformance-raa -- Bob Arning -- 24 November 2000 This is mostly a Mac issue, but may have some effect on other platforms. These changes do not take effect until you set the preference #higherPerformance to true. The impact of setting this pref to true may be higher performance for this Squeak image, but lower performance for other applications/processes that may be running concurrently. Experiment with your particular configuration/desires and decide for yourself. 1. In order to reduce the amount of time lost (perhaps 20 to 30% in some cases) to background applications on the Mac, change the strategy used to poll for UI events. Every time we poll the OS for UI events, increase the delay until the next check. Every time Squeak actually requests an event from EventSensor, reset the delay to its normal value (20 ms). This means that a long-running evaluation started in the UI process will receive less competition from background apps (and less overhead even if it is the only app), but normal UI-intensive operations will happen as they do now. What is lost by this change is some sensitivity to mouse events that occur while Squeak is busy over long periods. My thought is that if Squeak is so occupied for a period of seconds, these events are much less useful and perhaps even harmful. 2. Reduce the minimum morphic cycle time (MinCycleLapse) so that the frame rate (and, hence, running of #step methods) can proceed at greater than 50 frames per second. This can be quite beneficial to things like simulations that are run via #step. ---executable code follows" Preferences addPreference: #higherPerformance category: #performance default: false balloonHelp: 'May offer higer performance at the expense of other applications on your computer. See the comment in EventSensor>>higherPerformanceNotes for more details'.
2997DoubleInitFix-len -- Luciano -- 27 November 2000 Fix a double initialization problem in KlattVoice and Speaker."
2998TetrisFix -- Dan Ingalls -- 27 November 2000 Two fixes, suggested by Andreas Raab to make Tetris compliant with the new alignment protocols.
As I began messing around with the new event paradigm, I noted that KeyUp and KeyDown events pass individual Key Codes, rather than their ASCII equivalents.
Is there any reason that the ASCII equivalent, when available, is not carried somewhere in the keyUp/Down event objects? It would be convenient and, particularly for games, faster, to have that information be readily available without an additional lookup in some applications without having to process two separate events.
In the Macintosh implementation, this information is available beneath the scenes -- in fact, it is separately parsed out of a single MacOS event into two Squeak events. I'm not asking for a change in the semantics -- just the convenience of having both keycode and ascii equivalent in the same keydown record.
Or am I missing something?
From: "Andrew C. Greenberg" werdna@mucow.com As I began messing around with the new event paradigm, I noted that KeyUp and KeyDown events pass individual Key Codes, rather than their ASCII equivalents.
Is there any reason that the ASCII equivalent, when available, is not carried somewhere in the keyUp/Down event objects? It would be convenient and, particularly for games, faster, to have that information be readily available without an additional lookup in some applications without having to process two separate events.
In the Macintosh implementation, this information is available beneath the scenes -- in fact, it is separately parsed out of a single MacOS event into two Squeak events. I'm not asking for a change in the semantics -- just the convenience of having both keycode and ascii equivalent in the same keydown record.
Or am I missing something?
I don't think you're missing anything. In fact, MacOS-X gives you just key-up/key-down events that contain both the raw code as well as several translations. That seems the correct way of handling the situation.
Marcel
squeak-dev@lists.squeakfoundation.org