[squeak-dev] Re: Event filters for user input events (i.e. mouse clicks etc.)

Chris Muller ma.chris.m at gmail.com
Fri May 27 21:42:04 UTC 2016


On Fri, May 27, 2016 at 2:40 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
>
> On 27.05.2016, at 20:36, Chris Muller <asqueaker at gmail.com> wrote:
>
>> Hi Marcel, global keyboard shortcuts are important, a 1-microsecond
>> slowdown per event does not sound significant.  But, yes, for
>> performance critical code like event handling, its probably worth
>> adding an instvar than a dictionary lookup.
>>
>> I don't know under what case an event-type would ever change.  Events
>> are events generated by the input devices.  They should basically be
>> created and then immutable...
>>
>
> Unless you want a filter that turns a mouse click into a keypress, like for automation?

Instead of converting an event, shouldn't the automater-thingy just
push a new event?

The responsibility of Events is to interface the UI hardware
(keyboard, mouse, etc.) to some UI framework (MVC, Morphic).  They
represent the low-level, immutable "data" from the hardware,
interpreted by the UI framework.  IMHO, this "signal" between VM and
Morphic should remain a thin, clean, simple and raw encapsulation of
the data (i.e., getters and setters).  I don't think
application-specific behaviors belong way down there..  You mentioned,
automation?


More information about the Squeak-dev mailing list