tim Rowledge wrote
>> On 18-05-2016, at 9:25 AM, marcel.taeumel <

> Marcel.Taeumel@

> > wrote:
> 
>> The idea of using event filters to actually transform events is
>> interesting. 
> 
> Filters can often be useful. We have, for example, the various canvases
> and scroll-wrapping morphs which filter how input and output is seen by
> the wrapped bitmaps etc. An obvious event filter (and maybe a stupid one
> in the real world) would be one that centralises the mouse button
> swapping; if button swapping is turned on it, err, swaps the button value
> around.  Right now we have a centralised place in
> EventSensor>processEvent: for something that global (and seriously - for a
> mouse type event we check the platform name every time?) but having a type
> of filter involved at lower levels would allow some morphs to *not* get
> swapped buttons. I dunno, maybe useful for testing how the UI behaves on a
> different GUI?
> 
> If you pass your events *through* a filter instead of just having them on
> the side then you can do much more. 
> 
>> 
>> How would a fake event filter be triggered if not by real events?
> 
> If some morph/app has a suitable event filter then clearly we can
> transform any incoming event into any other kind of event (as long as it
> is one that the morph will not raise an error for) as they are sent by the
> whole Hand/PasteUp complex. To trigger a faking-filter I guess the best
> thing would be to throw a FakeEvent at the event handling code at whatever
> level you need (anywhere from the local world PasteUpMorph on down to your
> local morph of interest) and let you filter convert that to whatever it
> wants. Why not simply make the ‘actual’ event type and pass that in? You
> might have a variety of faking-filters doing different things and want to
> test them, maybe you want the FakeEvents to be easily assembled by parsing
> a socket stream or file, I don’t know. It just needs you to bypass the
> eventsensor and push an event.
> 
> I honestly don’t know if it’s an actually useful idea.
> 
> tim
> --
> tim Rowledge; 

> tim@

> ; http://www.rowledge.org/tim
> Asking whether machines can think is like asking whether submarines can
> swim.

Hi, there!

Here is another update:  event-filters.cs
<http://forum.world.st/file/n4896366/event-filters.cs>  

The filters should work now as expected. The change set includes a
refactoring of MorphicEventDispatcher and HandMorph >> #handleEvent:. Be
sure to update the trunk to the latest version before filing-in the change
set.

Then you can do things like "if you type a y, make a z out of it and vice
versa":

filter := PluggableEventFilter on: [:evt :target |
	(evt isKeyboard and: [evt keyCharacter = $z])
		ifTrue: [evt instVarNamed: #keyValue put: $y asInteger]
		ifFalse: [(evt isKeyboard and: [evt keyCharacter = $y])
			ifTrue: [evt instVarNamed: #keyValue put: $z asInteger]].
	evt].

ActiveHand addEventFilter: filter.
ActiveHand removeEventFilter: filter.

Best,
Marcel



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