Smalltalk › Squeak › Squeak VM

Miss-understanding mousewheel events

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 4 messages Options
Nicolas Cellier
Reply | Threaded
Open this post in threaded view
♦
♦
|

Miss-understanding mousewheel events

Nicolas Cellier
 
Hi all,
I'm in my way of implementing mousewheel events on windows VM.

If I understand it correctly, we fill the buttons field of the event buffer with modifiers states, and we don't fill the modifiers field of the event buffer...

This sounds very strange to me.
(I've commented the lines that I find questionable)
Eliot, do you remember why?

It gives this image code:

generateMouseWheelEvent: evtBuf
    ...snip...
     modifiers := evtBuf fifth.
    buttons := (modifiers bitShift: 3) bitOr: (lastMouseEvent buttons bitAnd: 7).

while other mouse events are:

generateMouseEvent: evtBuf
    ...snip...
     buttons := evtBuf fifth.
     modifiers := evtBuf sixth.

I'd be happy to see more uniformity, sixth field is not used.
marcel.taeumel
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Miss-understanding mousewheel events

marcel.taeumel
 
Hi Nicolas,

I tried to document that in EventSensor class comment:

...
Mouse-wheel event structure
==========================
Mouse-wheel events are generated when mouse-wheel input is detected.
[1] - event type 7
[2] - time stamp
[3] - horizontal scroll delta
[4] - vertical scroll delta
[5] - button state (same as in mouse events)
[6] - modifier keys (same as in mouse events)
[7] - reserved.
[8] - host window id.
...

SHIFT + RED + WHEEL-UP should be possible, right?

RED -> [5]
SHIFT -> [6]
WHEEL UP -> [3]

Best,
Marcel

Am 26.12.2019 00:42:49 schrieb Nicolas Cellier <[hidden email]>:

Hi all,
I'm in my way of implementing mousewheel events on windows VM.

If I understand it correctly, we fill the buttons field of the event buffer
with modifiers states, and we don't fill the modifiers field of the event
buffer...

This sounds very strange to me.
See
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/897ef1725e32c2eb3d24e3402b2e95b114b8b28b
(I've commented the lines that I find questionable)
Eliot, do you remember why?

It gives this image code:

generateMouseWheelEvent: evtBuf
...snip...
modifiers := evtBuf fifth.
buttons := (modifiers bitShift: 3) bitOr: (lastMouseEvent buttons
bitAnd: 7).

while other mouse events are:

generateMouseEvent: evtBuf
...snip...
buttons := evtBuf fifth.
modifiers := evtBuf sixth.

I'd be happy to see more uniformity, sixth field is not used.
Hi all,
I'm in my way of implementing mousewheel events on windows VM.

If I understand it correctly, we fill the buttons field of the event buffer with modifiers states, and we don't fill the modifiers field of the event buffer...

This sounds very strange to me.
(I've commented the lines that I find questionable)
Eliot, do you remember why?

It gives this image code:

generateMouseWheelEvent: evtBuf
    ...snip...
     modifiers := evtBuf fifth.
    buttons := (modifiers bitShift: 3) bitOr: (lastMouseEvent buttons bitAnd: 7).

while other mouse events are:

generateMouseEvent: evtBuf
    ...snip...
     buttons := evtBuf fifth.
     modifiers := evtBuf sixth.

I'd be happy to see more uniformity, sixth field is not used.
marcel.taeumel
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Miss-understanding mousewheel events

marcel.taeumel
 
Also note that "(lastMouseEvent buttons bitAnd: 7)" reads the #buttons field  in the event object, which combines field 5 and 6 of the raw mouse-event array.

Best,
Marcel

Am 26.12.2019 15:48:23 schrieb Marcel Taeumel <[hidden email]>:

Hi Nicolas,

I tried to document that in EventSensor class comment:

...
Mouse-wheel event structure
==========================
Mouse-wheel events are generated when mouse-wheel input is detected.
[1] - event type 7
[2] - time stamp
[3] - horizontal scroll delta
[4] - vertical scroll delta
[5] - button state (same as in mouse events)
[6] - modifier keys (same as in mouse events)
[7] - reserved.
[8] - host window id.
...

SHIFT + RED + WHEEL-UP should be possible, right?

RED -> [5]
SHIFT -> [6]
WHEEL UP -> [3]

Best,
Marcel

Am 26.12.2019 00:42:49 schrieb Nicolas Cellier <[hidden email]>:

Hi all,
I'm in my way of implementing mousewheel events on windows VM.

If I understand it correctly, we fill the buttons field of the event buffer
with modifiers states, and we don't fill the modifiers field of the event
buffer...

This sounds very strange to me.
See
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/897ef1725e32c2eb3d24e3402b2e95b114b8b28b
(I've commented the lines that I find questionable)
Eliot, do you remember why?

It gives this image code:

generateMouseWheelEvent: evtBuf
...snip...
modifiers := evtBuf fifth.
buttons := (modifiers bitShift: 3) bitOr: (lastMouseEvent buttons
bitAnd: 7).

while other mouse events are:

generateMouseEvent: evtBuf
...snip...
buttons := evtBuf fifth.
modifiers := evtBuf sixth.

I'd be happy to see more uniformity, sixth field is not used.
Hi all,
I'm in my way of implementing mousewheel events on windows VM.

If I understand it correctly, we fill the buttons field of the event buffer with modifiers states, and we don't fill the modifiers field of the event buffer...

This sounds very strange to me.
(I've commented the lines that I find questionable)
Eliot, do you remember why?

It gives this image code:

generateMouseWheelEvent: evtBuf
    ...snip...
     modifiers := evtBuf fifth.
    buttons := (modifiers bitShift: 3) bitOr: (lastMouseEvent buttons bitAnd: 7).

while other mouse events are:

generateMouseEvent: evtBuf
    ...snip...
     buttons := evtBuf fifth.
     modifiers := evtBuf sixth.

I'd be happy to see more uniformity, sixth field is not used.
Nicolas Cellier
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Miss-understanding mousewheel events

Nicolas Cellier
 
Hi Marcel,
I'm fine with that, we want to have MouseWheelEvent structure matching that of other MouseEvent at image side.
My question was why the hell having a different field usage at VM side!

Le jeu. 26 déc. 2019 à 15:50, Marcel Taeumel <[hidden email]> a écrit :
 
Also note that "(lastMouseEvent buttons bitAnd: 7)" reads the #buttons field  in the event object, which combines field 5 and 6 of the raw mouse-event array.

This is the part that I don't want to see.
I understand that you did that because of VM deficiency to provide those states.
The question is again, why the hell wouldn't the VM deliver those states?

Best,
Marcel

Am 26.12.2019 15:48:23 schrieb Marcel Taeumel <[hidden email]>:

Hi Nicolas,

I tried to document that in EventSensor class comment:

...
Mouse-wheel event structure
==========================
Mouse-wheel events are generated when mouse-wheel input is detected.
[1] - event type 7
[2] - time stamp
[3] - horizontal scroll delta
[4] - vertical scroll delta
[5] - button state (same as in mouse events)
[6] - modifier keys (same as in mouse events)
[7] - reserved.
[8] - host window id.
...

SHIFT + RED + WHEEL-UP should be possible, right?

RED -> [5]
SHIFT -> [6]
WHEEL UP -> [3]

Best,
Marcel

Am 26.12.2019 00:42:49 schrieb Nicolas Cellier <[hidden email]>:

Hi all,
I'm in my way of implementing mousewheel events on windows VM.

If I understand it correctly, we fill the buttons field of the event buffer
with modifiers states, and we don't fill the modifiers field of the event
buffer...

This sounds very strange to me.
See
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/897ef1725e32c2eb3d24e3402b2e95b114b8b28b
(I've commented the lines that I find questionable)
Eliot, do you remember why?

It gives this image code:

generateMouseWheelEvent: evtBuf
...snip...
modifiers := evtBuf fifth.
buttons := (modifiers bitShift: 3) bitOr: (lastMouseEvent buttons
bitAnd: 7).

while other mouse events are:

generateMouseEvent: evtBuf
...snip...
buttons := evtBuf fifth.
modifiers := evtBuf sixth.

I'd be happy to see more uniformity, sixth field is not used.
Hi all,
I'm in my way of implementing mousewheel events on windows VM.

If I understand it correctly, we fill the buttons field of the event buffer with modifiers states, and we don't fill the modifiers field of the event buffer...

This sounds very strange to me.
(I've commented the lines that I find questionable)
Eliot, do you remember why?

It gives this image code:

generateMouseWheelEvent: evtBuf
    ...snip...
     modifiers := evtBuf fifth.
    buttons := (modifiers bitShift: 3) bitOr: (lastMouseEvent buttons bitAnd: 7).

while other mouse events are:

generateMouseEvent: evtBuf
    ...snip...
     buttons := evtBuf fifth.
     modifiers := evtBuf sixth.

I'd be happy to see more uniformity, sixth field is not used.
Free forum by Nabble Edit this page