Chris Muller-4 wrote
> On Fri, May 27, 2016 at 2:40 PM, Tobias Pape <

> Das.Linux@

> > wrote:
>>
>> On 27.05.2016, at 20:36, Chris Muller <

> asqueaker@

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

If you want to convert a mouse click into a keypress for automation, you
would have two options to write a global/hand capture filter:

1st option) Write a mouse filter that ignores the given click event,
generates a keyboard event, and processes that keyboard event via
"givenMouseEvent hand processEvent: newKeyboardEvent.". Eventually, return
that original (but ignored) mouse event. 

2nd option) Write a mouse filter that just generates a keyboard event and
returns that.

I want to ensure that both options yield the same results to mitigate
programming errors. The 1st option would trigger all active filters again,
and hence also keyboard filters, because event processing starts again. The
2nd option continues the current event processing and hence should also
trigger global keyboard filters (again). Just make option 1 behave like
option 2.

@Chris: Yes, such event filters are specific to Morphic. In MVC, such
filters do still not exist. The code that I added resides in Morph,
HandMorph, and MorphEventDispatcher. However, we should consider moving the
UserInputEvent tree out of Morphic into the base system for other frameworks
to work with user input events in an object-oriented fashion. :-) One could
also implement generic event filters in EventSensor >> #nextEvent but this
is not what I had in mind here. Our global keyboard shortcuts are for
Morphic only.

Best,
Marcel



--
View this message in context: http://forum.world.st/Event-filters-for-user-input-events-i-e-mouse-clicks-etc-tp4895521p4897982.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.