Smalltalk › Squeak › Squeak - Dev

Mouse Wheel Events, "Point and scroll-by-wheel"

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

15 messages Options

marcel.taeumel

Mouse Wheel Events, "Point and scroll-by-wheel"

Hi, there.

Here is a change set that adds MouseWheelEvent and everything related to it (including EventHandler):
mouse-wheel-events.cs

You have two new preferences (in "Morphic", "keyboard", "mouse" categories):

[x] Synthesize Mouse Wheel Events from Keyboard Events
[x] Send Mouse Wheel Events to Keyboard Focus

Both are enabled by default.

I refactored the old-style wheel scrolling to use an event filter in ScrollPane but this is regarded a fall-back only and can be used for old applications.

The mouse wheel event synthesis is implemented as keyboard event capture filter in HandMorph itself. See the changeset's postload script or HandMorph >> #initForEvents. Once our VMs deliver real mouse wheel events, we can change that and adapt HandMorph >> #generateMouseEvent:.

The preferences "Send Mouse Wheel Events to Keyboard Focus" can be used to switch between Windows and OS X behavior.

Please, try it out.

Best,
Marcel

Chris Muller-3

Re: Mouse Wheel Events, "Point and scroll-by-wheel"

It makes scrolling very choppy. Instead of scrolling by 3-lines at a
time, it scrolls by about 10...

Shouldn't "Send Mouse Wheel Events to Keyboard Focus" be controlled by
mouseOverForKeyboardFocus?

On Mon, Jun 6, 2016 at 10:50 AM, marcel.taeumel <[hidden email]> wrote:

> Hi, there.
>
> Here is a change set that adds MouseWheelEvent and everything related to it
> (including EventHandler):
> mouse-wheel-events.cs
> <http://forum.world.st/file/n4899428/mouse-wheel-events.cs>
>
> You have two new preferences (in "Morphic", "keyboard", "mouse" categories):
>
> [x] Synthesize Mouse Wheel Events from Keyboard Events
> [x] Send Mouse Wheel Events to Keyboard Focus
>
> Both are enabled by default.
>
> I refactored the old-style wheel scrolling to use an event filter in
> ScrollPane but this is regarded a fall-back only and can be used for old
> applications.
>
> The mouse wheel event synthesis is implemented as keyboard event capture
> filter in HandMorph itself. See the changeset's postload script or HandMorph
>>> #initForEvents. Once our VMs deliver real mouse wheel events, we can
> change that and adapt HandMorph >> #generateMouseEvent:.
>
> The preferences "Send Mouse Wheel Events to Keyboard Focus" can be used to
> switch between Windows and OS X behavior.
>
> Please, try it out.
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/Mouse-Wheel-Events-Point-and-scroll-by-wheel-tp4899428.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>

marcel.taeumel

Re: Mouse Wheel Events, "Point and scroll-by-wheel"

Chris Muller-3 wrote

It makes scrolling very choppy. Instead of scrolling by 3-lines at a
time, it scrolls by about 10...

Shouldn't "Send Mouse Wheel Events to Keyboard Focus" be controlled by
mouseOverForKeyboardFocus?

On Mon, Jun 6, 2016 at 10:50 AM, marcel.taeumel <[hidden email]> wrote:
> Hi, there.
>
> Here is a change set that adds MouseWheelEvent and everything related to it
> (including EventHandler):
> mouse-wheel-events.cs
> <http://forum.world.st/file/n4899428/mouse-wheel-events.cs>
>
> You have two new preferences (in "Morphic", "keyboard", "mouse" categories):
>
> [x] Synthesize Mouse Wheel Events from Keyboard Events
> [x] Send Mouse Wheel Events to Keyboard Focus
>
> Both are enabled by default.
>
> I refactored the old-style wheel scrolling to use an event filter in
> ScrollPane but this is regarded a fall-back only and can be used for old
> applications.
>
> The mouse wheel event synthesis is implemented as keyboard event capture
> filter in HandMorph itself. See the changeset's postload script or HandMorph
>>> #initForEvents. Once our VMs deliver real mouse wheel events, we can
> change that and adapt HandMorph >> #generateMouseEvent:.
>
> The preferences "Send Mouse Wheel Events to Keyboard Focus" can be used to
> switch between Windows and OS X behavior.
>
> Please, try it out.
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/Mouse-Wheel-Events-Point-and-scroll-by-wheel-tp4899428.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>

Hi Chris,

there should be no change in the observable behavior by this change. In my image, it still scrolls 3 text lines in a text morph and 3 items in a list morph. This is specified in ScrollPane >> #mouseWheel: (resp: ScrollPane >> #scrollByKeyboard:). Could you please inspect the vertical scrollbar of one text morph and one list morph and tell me the value of "scrollDelta"? And, if you have time, could you try it in a fresh Squeak Trunk image? You are working under Ubuntu Linux?

If the preference #mouseOverForKeyboardFocus is enabled, "Send Mouse Wheel to Keyboard Focus" has no effect because the keyboard focus is always where the mouse cursor is. However, there are many users that do disable #mouseOverForKeyboardFocus and wished for the Mac behavior for a very long time. Bert, for example. Now, you can make scrolling by mouse wheel behave like on the Mac:

[ ] mouseOverForKeyboardFocus
[x] Send Mouse Wheel Events to Keyboard Focus
[x] Synthesize Mouse Wheel Events from Keyboard Events

Best,
Marcel

Chris Muller-3

Re: Mouse Wheel Events, "Point and scroll-by-wheel"

Hi,

> there should be no change in the observable behavior by this change. In my
> image, it still scrolls 3 text lines in a text morph and 3 items in a list
> morph. This is specified in ScrollPane >> #mouseWheel: (resp: ScrollPane >>
> #scrollByKeyboard:). Could you please inspect the vertical scrollbar of one
> text morph and one list morph and tell me the value of "scrollDelta"?

16 and 14, respectively.

> And,
> if you have time, could you try it in a fresh Squeak Trunk image? You are
> working under Ubuntu Linux?

Yep.

> If the preference #mouseOverForKeyboardFocus is enabled, "Send Mouse Wheel
> to Keyboard Focus" has no effect because the keyboard focus is always where
> the mouse cursor is. However, there are many users that do disable
> #mouseOverForKeyboardFocus and wished for the Mac behavior for a very long
> time. Bert, for example. Now, you can make scrolling by mouse wheel behave
> like on the Mac:
>
> [ ] mouseOverForKeyboardFocus
> [x] Send Mouse Wheel Events to Keyboard Focus
> [x] Synthesize Mouse Wheel Events from Keyboard Events

Ah, okay, I can see it would slightly alleviates the pain of
click-for-focus. It seemed strange for a moment to imagine why the
wheel should scrol one list, but use of the arrows or filtering keys
would be directed to a different widget.

Bert Freudenberg

Re: Mouse Wheel Events, "Point and scroll-by-wheel"

In reply to this post by marcel.taeumel

On 07.06.2016, at 08:25, marcel.taeumel <[hidden email]> wrote:
>
> Chris Muller-3 wrote
>> It makes scrolling very choppy. Instead of scrolling by 3-lines at a
>> time, it scrolls by about 10...
>
> Hi Chris,
>
> there should be no change in the observable behavior by this change.

I like being able to point-and-scroll inactive windows very much.

But if we are not using keyboard events anymore, we should switch to smooth scrolling, right? Like that legendary one-line change Dan did at Steve’s PARC visit to change from line-based to pixel-based scrolling? Wonder how many lines of code it takes us ;)

- Bert -

smime.p7s (5K) Download Attachment

marcel.taeumel

Re: Mouse Wheel Events, "Point and scroll-by-wheel"

Bert Freudenberg wrote

On 07.06.2016, at 08:25, marcel.taeumel <[hidden email]> wrote:
>
> Chris Muller-3 wrote
>> It makes scrolling very choppy. Instead of scrolling by 3-lines at a
>> time, it scrolls by about 10...
>
> Hi Chris,
>
> there should be no change in the observable behavior by this change.

I like being able to point-and-scroll inactive windows very much.

But if we are not using keyboard events anymore, we should switch to smooth scrolling, right? Like that legendary one-line change Dan did at Steve’s PARC visit to change from line-based to pixel-based scrolling? Wonder how many lines of code it takes us ;)

- Bert -

smime.p7s (5K) <http://forum.world.st/attachment/4899870/0/smime.p7s>

Hi Bert,

sure, it is a one-liner. Just change PluggableListMorph >> #scrollDeltaHeight. ... and PluggableTextMorph >> #scrollDeltaHeight. :-) Return 1 instead of the font height. You might want to call this then:

ScrollPane allSubInstancesDo: [:ea | ea vSetScrollDelta].

However, using a regular mouse with a non-free wheel (i.e., one that has "clicks"), this would make scrolling very cumbersome.

So, if you had real touch/swipe events and could do kinetic scrolling... this would we very cool. :)

Best,
Marcel

Tony Garnock-Jones-3

Touchscreen events and non-blocking file I/O (was Re: Mouse Wheel Events, "Point and scroll-by-wheel")

On 06/08/2016 11:03 AM, marcel.taeumel wrote:
> So, if you had real touch/swipe events and could do kinetic scrolling...
> this would we very cool. :)

I've previously tried to read touchscreen events on Linux from
/dev/input/event*, but ran into trouble because the Squeak VMs I tried
all treat "file I/O" as blocking - that is, bytes will be immediately
available, or end-of-file will be immediately available.

This is, of course, not true for /dev/input/event* ! Reading from such
files is much more like reading from a socket.

Does any kind of plugin or overlooked primitive exist that'd allow for
non-blocking reads from /dev/input/event* pseudofiles?

Tony

Levente Uzonyi

Re: Touchscreen events and non-blocking file I/O (was Re: Mouse Wheel Events, "Point and scroll-by-wheel")

On Wed, 8 Jun 2016, Tony Garnock-Jones wrote:

> On 06/08/2016 11:03 AM, marcel.taeumel wrote:
>> So, if you had real touch/swipe events and could do kinetic scrolling...
>> this would we very cool. :)
>
> I've previously tried to read touchscreen events on Linux from
> /dev/input/event*, but ran into trouble because the Squeak VMs I tried
> all treat "file I/O" as blocking - that is, bytes will be immediately
> available, or end-of-file will be immediately available.
>
> This is, of course, not true for /dev/input/event* ! Reading from such
> files is much more like reading from a socket.
>
> Does any kind of plugin or overlooked primitive exist that'd allow for
> non-blocking reads from /dev/input/event* pseudofiles?

I guess you can use the AIO plugin for that, or you can use OSProcess,
which also uses the AIO plugin for non-blocking reads.

Levente

>
> Tony
>
>

Tony Garnock-Jones-3

Re: Touchscreen events and non-blocking file I/O (was Re: Mouse Wheel Events, "Point and scroll-by-wheel")

On 06/08/2016 01:43 PM, Levente Uzonyi wrote:
> I guess you can use the AIO plugin for that, or you can use OSProcess,
> which also uses the AIO plugin for non-blocking reads.

Great! Thank you, I'll give it a shot!

Regards,
Tony

Tony Garnock-Jones-3

Successful reading of /dev/input/event2 (was Re: Touchscreen events and non-blocking file I/O)

Hello all,

Following Levente's suggestion, I managed to read Linux input events
from /dev/input/event2 (which is a mouse on this system) without
blocking the whole image.

Attached is LinuxIO.st. To try it out,

d := LinuxInputEventDevice openPath: '/dev/input/event2'.
d eventHandler:
[:e | Transcript nextPutAll: e printString; crlf; flush].

(Change event2 to the device file for your mouse - or touchscreen!)

Then, wiggling the mouse should print messages to Transcript.

To stop it,

d close.

(You can start it again with "d open".)

It's just a proof-of-concept; ideally, it'd know to reopen itself at
image startup. Plus it'd be useful to have some way of identifying at
least device classes. But it's good enough to start playing with reading
touchscreens, perhaps!

Regards,
Tony

LinuxIO.st (4K) Download Attachment

David T. Lewis

Re: Successful reading of /dev/input/event2 (was Re: Touchscreen events and non-blocking file I/O)

Very nice, thanks for posting this.

Dave

On Wed, Jun 08, 2016 at 05:28:00PM -0400, Tony Garnock-Jones wrote:

> Hello all,
>
> Following Levente's suggestion, I managed to read Linux input events
> from /dev/input/event2 (which is a mouse on this system) without
> blocking the whole image.
>
> Attached is LinuxIO.st. To try it out,
>
> d := LinuxInputEventDevice openPath: '/dev/input/event2'.
> d eventHandler:
> [:e | Transcript nextPutAll: e printString; crlf; flush].
>
> (Change event2 to the device file for your mouse - or touchscreen!)
>
> Then, wiggling the mouse should print messages to Transcript.
>
> To stop it,
>
> d close.
>
> (You can start it again with "d open".)
>
> It's just a proof-of-concept; ideally, it'd know to reopen itself at
> image startup. Plus it'd be useful to have some way of identifying at
> least device classes. But it's good enough to start playing with reading
> touchscreens, perhaps!
>
> Regards,
> Tony
>

Chris Muller-3

Re: Mouse Wheel Events, "Point and scroll-by-wheel"

In reply to this post by marcel.taeumel

Hi Marcel, I updated a fresh Squeak5.1-15113 image. After the update,
the scrolling jumps to a chunky 9 lines per tick, and Control+[Up
Arrow] or Control+[Down Arrow] seems to "triple scroll" for each press
-- as if I had pressed it three times...

Maybe the problems are related?

On Tue, Jun 7, 2016 at 1:25 AM, marcel.taeumel <[hidden email]> wrote:

> Chris Muller-3 wrote
>> It makes scrolling very choppy. Instead of scrolling by 3-lines at a
>> time, it scrolls by about 10...
>>
>> Shouldn't "Send Mouse Wheel Events to Keyboard Focus" be controlled by
>> mouseOverForKeyboardFocus?
>>
>> On Mon, Jun 6, 2016 at 10:50 AM, marcel.taeumel <
>
>> Marcel.Taeumel@
>
>> > wrote:
>>> Hi, there.
>>>
>>> Here is a change set that adds MouseWheelEvent and everything related to
>>> it
>>> (including EventHandler):
>>> mouse-wheel-events.cs
>>> <http://forum.world.st/file/n4899428/mouse-wheel-events.cs>
>>>
>>> You have two new preferences (in "Morphic", "keyboard", "mouse"
>>> categories):
>>>
>>> [x] Synthesize Mouse Wheel Events from Keyboard Events
>>> [x] Send Mouse Wheel Events to Keyboard Focus
>>>
>>> Both are enabled by default.
>>>
>>> I refactored the old-style wheel scrolling to use an event filter in
>>> ScrollPane but this is regarded a fall-back only and can be used for old
>>> applications.
>>>
>>> The mouse wheel event synthesis is implemented as keyboard event capture
>>> filter in HandMorph itself. See the changeset's postload script or
>>> HandMorph
>>>>> #initForEvents. Once our VMs deliver real mouse wheel events, we can
>>> change that and adapt HandMorph >> #generateMouseEvent:.
>>>
>>> The preferences "Send Mouse Wheel Events to Keyboard Focus" can be used
>>> to
>>> switch between Windows and OS X behavior.
>>>
>>> Please, try it out.
>>>
>>> Best,
>>> Marcel
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://forum.world.st/Mouse-Wheel-Events-Point-and-scroll-by-wheel-tp4899428.html
>>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>>>
>
> Hi Chris,
>
> there should be no change in the observable behavior by this change. In my
> image, it still scrolls 3 text lines in a text morph and 3 items in a list
> morph. This is specified in ScrollPane >> #mouseWheel: (resp: ScrollPane >>
> #scrollByKeyboard:). Could you please inspect the vertical scrollbar of one
> text morph and one list morph and tell me the value of "scrollDelta"? And,
> if you have time, could you try it in a fresh Squeak Trunk image? You are
> working under Ubuntu Linux?
>
> If the preference #mouseOverForKeyboardFocus is enabled, "Send Mouse Wheel
> to Keyboard Focus" has no effect because the keyboard focus is always where
> the mouse cursor is. However, there are many users that do disable
> #mouseOverForKeyboardFocus and wished for the Mac behavior for a very long
> time. Bert, for example. Now, you can make scrolling by mouse wheel behave
> like on the Mac:
>
> [ ] mouseOverForKeyboardFocus
> [x] Send Mouse Wheel Events to Keyboard Focus
> [x] Synthesize Mouse Wheel Events from Keyboard Events
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/Mouse-Wheel-Events-Point-and-scroll-by-wheel-tp4899428p4899504.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>

marcel.taeumel

Re: Mouse Wheel Events, "Point and scroll-by-wheel"

Chris Muller-3 wrote

Hi Marcel, I updated a fresh Squeak5.1-15113 image. After the update,
the scrolling jumps to a chunky 9 lines per tick, and Control+[Up
Arrow] or Control+[Down Arrow] seems to "triple scroll" for each press
-- as if I had pressed it three times...

Maybe the problems are related?

On Tue, Jun 7, 2016 at 1:25 AM, marcel.taeumel <[hidden email]> wrote:
> Chris Muller-3 wrote
>> It makes scrolling very choppy. Instead of scrolling by 3-lines at a
>> time, it scrolls by about 10...
>>
>> Shouldn't "Send Mouse Wheel Events to Keyboard Focus" be controlled by
>> mouseOverForKeyboardFocus?
>>
>> On Mon, Jun 6, 2016 at 10:50 AM, marcel.taeumel <
>
>> Marcel.Taeumel@
>
>> > wrote:
>>> Hi, there.
>>>
>>> Here is a change set that adds MouseWheelEvent and everything related to
>>> it
>>> (including EventHandler):
>>> mouse-wheel-events.cs
>>> <http://forum.world.st/file/n4899428/mouse-wheel-events.cs>
>>>
>>> You have two new preferences (in "Morphic", "keyboard", "mouse"
>>> categories):
>>>
>>> [x] Synthesize Mouse Wheel Events from Keyboard Events
>>> [x] Send Mouse Wheel Events to Keyboard Focus
>>>
>>> Both are enabled by default.
>>>
>>> I refactored the old-style wheel scrolling to use an event filter in
>>> ScrollPane but this is regarded a fall-back only and can be used for old
>>> applications.
>>>
>>> The mouse wheel event synthesis is implemented as keyboard event capture
>>> filter in HandMorph itself. See the changeset's postload script or
>>> HandMorph
>>>>> #initForEvents. Once our VMs deliver real mouse wheel events, we can
>>> change that and adapt HandMorph >> #generateMouseEvent:.
>>>
>>> The preferences "Send Mouse Wheel Events to Keyboard Focus" can be used
>>> to
>>> switch between Windows and OS X behavior.
>>>
>>> Please, try it out.
>>>
>>> Best,
>>> Marcel
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://forum.world.st/Mouse-Wheel-Events-Point-and-scroll-by-wheel-tp4899428.html
>>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>>>
>
> Hi Chris,
>
> there should be no change in the observable behavior by this change. In my
> image, it still scrolls 3 text lines in a text morph and 3 items in a list
> morph. This is specified in ScrollPane >> #mouseWheel: (resp: ScrollPane >>
> #scrollByKeyboard:). Could you please inspect the vertical scrollbar of one
> text morph and one list morph and tell me the value of "scrollDelta"? And,
> if you have time, could you try it in a fresh Squeak Trunk image? You are
> working under Ubuntu Linux?
>
> If the preference #mouseOverForKeyboardFocus is enabled, "Send Mouse Wheel
> to Keyboard Focus" has no effect because the keyboard focus is always where
> the mouse cursor is. However, there are many users that do disable
> #mouseOverForKeyboardFocus and wished for the Mac behavior for a very long
> time. Bert, for example. Now, you can make scrolling by mouse wheel behave
> like on the Mac:
>
> [ ] mouseOverForKeyboardFocus
> [x] Send Mouse Wheel Events to Keyboard Focus
> [x] Synthesize Mouse Wheel Events from Keyboard Events
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/Mouse-Wheel-Events-Point-and-scroll-by-wheel-tp4899428p4899504.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>

Hi Chris,

is the behavior different if you disable "Synthesize Mouse Wheel Events from Keyboard Events"?

I did found a regression: http://forum.world.st/The-Trunk-Morphic-mt-1177-mcz-tp4900535.html

But this does not affect the filter in HandMorph where MouseWheel events are synthesized. Hmmm... What happens if you modify ScrollPane >> #mouseWheel: an change 3 to 1? Still, this is only a workaround because the 3 denotes 3 lines/items to scroll...

Hmmm.... can you monitor for me how many CTRL+up/down events are produced on your platform? Just add a "Transcript showln: anEvent" to HandMorph >> showEvent:, maybe with an "anEvent isKeyboard" check. How many do you get when you operate the mouse wheel? I get only keystrokes:

[275@294 keystroke '<Ctrl-down>' 514791296]
[275@294 keystroke '<Ctrl-up>' 514792218]
[275@294 keystroke '<Ctrl-down>' 514796140]
[275@294 keystroke '<Ctrl-up>' 514796593]
[275@294 keystroke '<Ctrl-down>' 514796890]
[275@294 keystroke '<Ctrl-up>' 514797171]
[275@294 keystroke '<Ctrl-down>' 514797484]
[275@294 keystroke '<Ctrl-up>' 514797843]
[275@294 keystroke '<Ctrl-down>' 514798281]

In a recent CogVM in Windows 10.

Best,
Marcel

Chris Muller-3

Re: Mouse Wheel Events, "Point and scroll-by-wheel"

I updated from trunk and it seems its fixed.

> is the behavior different if you disable "Synthesize Mouse Wheel Events from
> Keyboard Events"?
>
> I did found a regression:
> http://forum.world.st/The-Trunk-Morphic-mt-1177-mcz-tp4900535.html

That was it. Reverting this fix causes it to scroll by 9 lines instead of 3.
Thanks.

marcel.taeumel

Re: Mouse Wheel Events, "Point and scroll-by-wheel"

Chris Muller-3 wrote

I updated from trunk and it seems its fixed.

> is the behavior different if you disable "Synthesize Mouse Wheel Events from
> Keyboard Events"?
>
> I did found a regression:
> http://forum.world.st/The-Trunk-Morphic-mt-1177-mcz-tp4900535.html

That was it. Reverting this fix causes it to scroll by 9 lines instead of 3.
Thanks.

Hi Chris,

ah, good. I think it was like this:

1. You got three events: key down, key stroke, key up
2. Key down went into the event filter in the scroll pane and falsely used to scroll: 3 lines.
3. Keystroke was converted into mouse wheel and handled as mouse wheel: 3 lines.
4. Key up went into the event filter in the scroll pane and falsely used to scroll: 3 lines.

The fix corrected 2. and 4.

Best,
Marcel