[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
|