Re: [Pharo-project] simulating Mousewheel
Stéphane Ducasse schrieb: > Thanks > We should definitively invest in this part of the infrastructure. > I wanted to know on your machine the mouse wheel does not work > because on mac in the latest version I can use it. > > Stef > Oh, sorry, I did not explain my problem clearly: I am working on a laptop with no mousewheel available. I trap Button-2 drag events and transform them to (ctrl+up/down arrow) events, which is what Pharo processes as mousewheel. Scrolling by Button-2 drag is what applications like Acrobat reader or Firefox do as well. And Thinkpad Laptops offer a system wide setting to do this with all the scrollable Windows. Unfortunately they do it on a system level without sending events to the application, so it does not work with Morphic. Cheers, Chris ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] simulating Mousewheel
Stéphane Ducasse schrieb: > Thanks chris. I never got the time to sit and read all the changes mike did > for the inputEvent logic so my knowledge is bad in that area. Now I was > wondering when your mouse wheel turns to get button down events? Hello, See comment on MouseWheelEvent class - thats why I thought mapping to (ctrl+up/down arrow) is the pharo way to do it. Also that's what I can see coming in (examining InputEventFetcher) on WinXP when I use a mousewheel. I think MouseWheel is not cross platform compatible. Linux/X11 uses Buttons 4-5 instead. > > BTW "mouse event" ((eventBuffer at: 5) anyMask: 1) > > do you know if it would be possible to have eventBuffer isMouseEvent instead > of the above? unfortunately the object assigned to eventBuffer is an ordinary Array containing 'raw' event information. ( Described in comment on InputEventFetcher ). That is why I thought, there could be a place to make such things configurable on a higher level (dealing with event objects rather than raw data). Btw. I got confused with the Button colours: Comments should refer to blue Button not yellow. Thanks, Chris > Stef > > >> Running Pharo on an IBM Thinkpad with a trackpoint input device, I was a >> bit disappointed, that the autoscroll feature does not work in Pharo >> (pressing Button-2 and moving the mouse pointer should scroll the window >> below the mouse pointer). I took it as an exercise and the attached code >> does what I want, but it does not feel right (like not at the the right >> 'level'): Is there a place in the Morph hierarchy where such behavior >> changes could be plugged in? Or did I overlook a preference setting ;) ? > > :) > > >> Cheers, Chris >> >> >> Object subclass: #InputEventFetcher instanceVariableNames: 'eventHandlers >> fetcherProcess inputSemaphore mousewheel ycoord' classVariableNames: >> 'Default' poolDictionaries: 'EventSensorConstants' category: >> 'Kernel-Processes' >> >> InputEventFetcher>> signalEvent: eventBuffer "Signal the event buffer to >> all registered event handlers. Handlers need make sure to copy the buffer >> or extract the data otherwise, as the buffer will be reused." >> >> self simulateMousewheel: eventBuffer. >> >> self eventHandlers do: [:handler | handler handleEvent: eventBuffer] >> >> InputEventFetcher>> simulateMousewheel: eventBuffer "MOusewheel up: 2 >> time 30 0 2 0 0 1 MOusewheel down: 2 time 31 0 2 0 0 1 " >> >> | ycur keysym up down | keysym := nil. up := 30. down := 31. (eventBuffer >> at: 1) = 1 ifTrue: [ "mouse event" ((eventBuffer at: 5) anyMask: 1) ifTrue: >> [ "yellow button down" mousewheel ifFalse: [ "first time: do nothing" >> mousewheel := true. ycoord := eventBuffer at: 4 ] ifTrue: [ "handle >> movement" ycur := eventBuffer at: 4. ycur - ycoord > 1 ifTrue: [ keysym := >> down. ycoord := ycur ]. ycur - ycoord < -1 ifTrue: [ keysym := up. ycoord >> := ycur ]. keysym isNil ifTrue: [ "make it a Null event" eventBuffer at: 1 >> put: 0 ] ifFalse: [ eventBuffer at: 1 put: 2. eventBuffer at: 3 put: >> keysym. eventBuffer replaceFrom: 4 to: 8 with: #(0 2 0 0 1) ] ] ] ifFalse: >> [ "yellowbutton up" mousewheel := false ] ]. ^ >> eventBuffer___ Pharo-project >> mailing list Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] simulating Mousewheel
Running Pharo on an IBM Thinkpad with a trackpoint input device, I was a bit disappointed, that the autoscroll feature does not work in Pharo (pressing Button-2 and moving the mouse pointer should scroll the window below the mouse pointer). I took it as an exercise and the attached code does what I want, but it does not feel right (like not at the the right 'level'): Is there a place in the Morph hierarchy where such behavior changes could be plugged in? Or did I overlook a preference setting ;) ? Cheers, Chris Object subclass: #InputEventFetcher instanceVariableNames: 'eventHandlers fetcherProcess inputSemaphore mousewheel ycoord' classVariableNames: 'Default' poolDictionaries: 'EventSensorConstants' category: 'Kernel-Processes' InputEventFetcher>> signalEvent: eventBuffer "Signal the event buffer to all registered event handlers. Handlers need make sure to copy the buffer or extract the data otherwise, as the buffer will be reused." self simulateMousewheel: eventBuffer. self eventHandlers do: [:handler | handler handleEvent: eventBuffer] InputEventFetcher>> simulateMousewheel: eventBuffer "MOusewheel up: 2 time 30 0 2 0 0 1 MOusewheel down: 2 time 31 0 2 0 0 1 " | ycur keysym up down | keysym := nil. up := 30. down := 31. (eventBuffer at: 1) = 1 ifTrue: [ "mouse event" ((eventBuffer at: 5) anyMask: 1) ifTrue: [ "yellow button down" mousewheel ifFalse: [ "first time: do nothing" mousewheel := true. ycoord := eventBuffer at: 4 ] ifTrue: [ "handle movement" ycur := eventBuffer at: 4. ycur - ycoord > 1 ifTrue: [ keysym := down. ycoord := ycur ]. ycur - ycoord < -1 ifTrue: [ keysym := up. ycoord := ycur ]. keysym isNil ifTrue: [ "make it a Null event" eventBuffer at: 1 put: 0 ] ifFalse: [ eventBuffer at: 1 put: 2. eventBuffer at: 3 put: keysym. eventBuffer replaceFrom: 4 to: 8 with: #(0 2 0 0 1) ] ] ] ifFalse: [ "yellowbutton up" mousewheel := false ] ]. ^ eventBuffer___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] GoferApiTest failing (WinXP)
Lukas Renggli schrieb: >> running the tests in latest images PharoCore-1.1 and 1.0 on WinXP I see >> GoferApiTest>>#testSubDirectoryRepository failing. > > Are you sure that you use the latest Gofer code, because I think I > fixed that a while back. > I just ran the tests that come with PharoCore-1.0-10508 PharoCore-1.1-11196 using the image as it is. I updated to Gofer-Tests lr.115 and now I see, that #testSubDirectoryRepository has been removed in that version... >> It could be fixed by changing >> >> MCSubDirectoryRepository>>#description >> >> + ^ directory pathName, FileDirectory slash , '*' >> - ^ directory pathName, '/*' >> >> The current implementation works because '/' and '\' both are valid path >> separators on windows. Assuming '/' as path delimiter would cause trouble >> with >> MacFileDirectory - but that might be obsolete anyway. >> So may be the test is too strict? > > I bet that breaks the tests on all platforms other than Windows. Why do you think so? Is 'FileDirectory slash' broken on platforms other than Windows? Cheers, Christoph ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] GoferApiTest failing (WinXP)
Hello to everybody,
running the tests in latest images PharoCore-1.1 and 1.0 on WinXP I see
GoferApiTest>>#testSubDirectoryRepository failing.
It could be fixed by changing
MCSubDirectoryRepository>>#description
+ ^ directory pathName, FileDirectory slash , '*'
- ^ directory pathName, '/*'
The current implementation works because '/' and '\' both are valid path
separators on windows. Assuming '/' as path delimiter would cause trouble with
MacFileDirectory - but that might be obsolete anyway.
So may be the test is too strict?
I just started to follow this list and the Pharo project ('Recreational
programmer' btw. - thanks for the kind welcome message ;) ). Should I report
this? And if so: It is a MC issue, should it be reported using the Pharo
tracker
or somewere else?
Cheers, Christoph
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
