Some Sensor refactorings ?
John M McIntosh
johnmci at smalltalkconsulting.com
Mon Nov 14 11:05:56 UTC 2005
One of the other fun things in here would be to nail down the UI
behavior between platforms.
The UI premise for key up/down/repeat has lately change on the mac to
more closely match Windows.
How keystrokes are recognized is different between Morphic and Tweak.
How mouse move/double click/click/up/down event could be different
between mac/windows (witness crusty code in morphic to *fix* mac
Certain how dead keys and multiple keystroke characters result in key
up/down keychar events would be interesting to understand between
Where and what is the Mac Roman key code, the virtual keycode, and
the unicode keycode come from and when?
On 14-Nov-05, at 12:43 AM, stéphane ducasse wrote:
> Hi guys
> I remember that john talked to me about that at ESUG in 2004 :).
> It would be good if you would propose something and that we cut and
> clean the situation (even stepwise).
> But I'm not sure that this is possible with morphic.
>>>> Hi all,
>>>> i started to look at the Sensor stuff. I have two questions :
>>>> - there is two classes : EventSensor and InputSensor. The first
>>>> one seems to be a replacement of the last one. Do we really need
>>>> two classes or could we try to merge both ?
>>> IMHO there's nothing wrong with having both classes. In a minimal
>>> image / VM the old polling InputSensor should actually still
>>> work. Which is good for getting new ports started. If the VM
>>> implements the event primitives, the EventSensor will take over.
>> Sadly this isn't how it works any longer. If you look deep into
>> the code (which of course allows the code to look deep into you)
>> you will see that the 'old' input sensor code cannot get to run.
>> Once upon a time entering an MVC project would awaken a simple
>> InputSensor for example. I did make some suggestions for a cleaner
>> input handler a while ago but no one seemed to care enough to even
>> want to discuss it. There's a related email at http://
>> There isn't really anything simpler about the old polling prims
>> than the newer sort-of event prims so we don't really have any
>> good reason to keep them. I was planning on cutting them out
>> sometime soon along with lots of other extraneous junk.
>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
More information about the Squeak-dev