In latest image the mouse seem to scroll sliders just by mouse over the scroll bar. It's a very unusual behavior, and I think I would like to opt out of it.
Is there a preference or is this a bug ?
Karl
The scrolling bug is caused by this change:
http://source.squeak.org/trunk/Morphic-cmm.984.mcz
Morph>>handlesMouseMove: anEvent "Do I want to receive mouseMove: when the hand passes over the receiver? Rules say that by default a morph gets #mouseMove iff * the hand is not dragging anything, + and some button is down, + and the receiver is the current mouse focus." ---> self eventHandler ifNotNil: [^ self eventHandler handlesMouseMove: anEvent]. <------- anEvent hand hasSubmorphs ifTrue: [ ^ false ]. (anEvent anyButtonPressed and: [ anEvent hand mouseFocus == self ]) ifFalse: [ ^ false ]. ^ true
There seem to be some unintended behavior because of this change.
Karl
On Mon, Jun 1, 2015 at 10:11 PM, karl ramberg karlramberg@gmail.com wrote:
In latest image the mouse seem to scroll sliders just by mouse over the scroll bar. It's a very unusual behavior, and I think I would like to opt out of it.
Is there a preference or is this a bug ?
Karl
I can't recreate the problem. What browser are you using?
The change you mention is consistent with every other type of event handling. It may have exposed another bug somewhere else, but I don't think it should be considered a bug, itself.
On Mon, Jun 1, 2015 at 3:20 PM, karl ramberg karlramberg@gmail.com wrote:
The scrolling bug is caused by this change:
http://source.squeak.org/trunk/Morphic-cmm.984.mcz
Morph>>handlesMouseMove: anEvent "Do I want to receive mouseMove: when the hand passes over the receiver? Rules say that by default a morph gets #mouseMove iff
- the hand is not dragging anything,
- and some button is down,
- and the receiver is the current mouse focus."
---> self eventHandler ifNotNil: [^ self eventHandler handlesMouseMove: anEvent]. <------- anEvent hand hasSubmorphs ifTrue: [ ^ false ]. (anEvent anyButtonPressed and: [ anEvent hand mouseFocus == self ]) ifFalse: [ ^ false ]. ^ true
There seem to be some unintended behavior because of this change.
Karl
On Mon, Jun 1, 2015 at 10:11 PM, karl ramberg karlramberg@gmail.com wrote:
In latest image the mouse seem to scroll sliders just by mouse over the scroll bar. It's a very unusual behavior, and I think I would like to opt out of it.
Is there a preference or is this a bug ?
Karl
Hi, All windows with scroll panes are affected, AFAICT. I'm on Spur, but I doubt that has any significance.
When I move the mouse over a scroll bar it scrolls without clicking on it. (Alas sometimes it stops auto-scrolling, without any clue why)
Is quite disorienting, stuff scrolls out of view as I move the mouse in and out of panes.
If this intended behavior, it must/should be made a preference.
Karl
On Mon, Jun 1, 2015 at 10:51 PM, Chris Muller asqueaker@gmail.com wrote:
I can't recreate the problem. What browser are you using?
The change you mention is consistent with every other type of event handling. It may have exposed another bug somewhere else, but I don't think it should be considered a bug, itself.
On Mon, Jun 1, 2015 at 3:20 PM, karl ramberg karlramberg@gmail.com wrote:
The scrolling bug is caused by this change:
http://source.squeak.org/trunk/Morphic-cmm.984.mcz
Morph>>handlesMouseMove: anEvent "Do I want to receive mouseMove: when the hand passes over the receiver? Rules say that by default a morph gets #mouseMove iff
- the hand is not dragging anything,
- and some button is down,
- and the receiver is the current mouse focus."
---> self eventHandler ifNotNil: [^ self eventHandler handlesMouseMove: anEvent]. <------- anEvent hand hasSubmorphs ifTrue: [ ^ false ]. (anEvent anyButtonPressed and: [ anEvent hand mouseFocus == self ])
ifFalse:
[ ^ false ]. ^ true
There seem to be some unintended behavior because of this change.
Karl
On Mon, Jun 1, 2015 at 10:11 PM, karl ramberg karlramberg@gmail.com
wrote:
In latest image the mouse seem to scroll sliders just by mouse over the scroll bar. It's a very unusual behavior, and I think I would like to opt out of it.
Is there a preference or is this a bug ?
Karl
On Tue, Jun 02, 2015 at 12:15:22AM +0200, karl ramberg wrote:
Hi, All windows with scroll panes are affected, AFAICT. I'm on Spur, but I doubt that has any significance.
When I move the mouse over a scroll bar it scrolls without clicking on it. (Alas sometimes it stops auto-scrolling, without any clue why)
I see the same thing, definitely not right.
Is quite disorienting, stuff scrolls out of view as I move the mouse in and out of panes.
If this intended behavior, it must/should be made a preference.
Please no preference. It's broken.
Dave
Karl
On Mon, Jun 1, 2015 at 10:51 PM, Chris Muller asqueaker@gmail.com wrote:
I can't recreate the problem. What browser are you using?
The change you mention is consistent with every other type of event handling. It may have exposed another bug somewhere else, but I don't think it should be considered a bug, itself.
On Mon, Jun 1, 2015 at 3:20 PM, karl ramberg karlramberg@gmail.com wrote:
The scrolling bug is caused by this change:
http://source.squeak.org/trunk/Morphic-cmm.984.mcz
Morph>>handlesMouseMove: anEvent "Do I want to receive mouseMove: when the hand passes over the receiver? Rules say that by default a morph gets #mouseMove iff
- the hand is not dragging anything,
- and some button is down,
- and the receiver is the current mouse focus."
---> self eventHandler ifNotNil: [^ self eventHandler handlesMouseMove: anEvent]. <------- anEvent hand hasSubmorphs ifTrue: [ ^ false ]. (anEvent anyButtonPressed and: [ anEvent hand mouseFocus == self ])
ifFalse:
[ ^ false ]. ^ true
There seem to be some unintended behavior because of this change.
Karl
On Mon, Jun 1, 2015 at 10:11 PM, karl ramberg karlramberg@gmail.com
wrote:
In latest image the mouse seem to scroll sliders just by mouse over the scroll bar. It's a very unusual behavior, and I think I would like to opt out of it.
Is there a preference or is this a bug ?
Karl
Chris' change is correct. The expectations in Slider >> #initializeSlider are kind of specific and do not match anymore. There, it is assumed that mouse-move events will only come after a mouse-down event -- not every time. The thing is that there may be many other places where this is assumed. Hmmm...
I propose this change: fix-mouse-move-bug.cs http://forum.world.st/file/n4829903/fix-mouse-move-bug.cs
It makes #wantsEveryMouseMove functional again and adds it to the EventHandler, too. It also duplicates the additional checks regarding mouse focus, submorphs, button down, etc.
Best, Marcel
-- View this message in context: http://forum.world.st/BUG-Automagic-scrolling-tp4829828p4829903.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
Hi, Change set works, Marcel :-)
Thanks, Karl
On Tue, Jun 2, 2015 at 9:47 AM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
Chris' change is correct. The expectations in Slider >> #initializeSlider are kind of specific and do not match anymore. There, it is assumed that mouse-move events will only come after a mouse-down event -- not every time. The thing is that there may be many other places where this is assumed. Hmmm...
I propose this change: fix-mouse-move-bug.cs http://forum.world.st/file/n4829903/fix-mouse-move-bug.cs
It makes #wantsEveryMouseMove functional again and adds it to the EventHandler, too. It also duplicates the additional checks regarding mouse focus, submorphs, button down, etc.
Best, Marcel
-- View this message in context: http://forum.world.st/BUG-Automagic-scrolling-tp4829828p4829903.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
It looks good to me too :-)
Dave
On Tue, Jun 02, 2015 at 12:53:04PM +0200, karl ramberg wrote:
Hi, Change set works, Marcel :-)
Thanks, Karl
On Tue, Jun 2, 2015 at 9:47 AM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
Chris' change is correct. The expectations in Slider >> #initializeSlider are kind of specific and do not match anymore. There, it is assumed that mouse-move events will only come after a mouse-down event -- not every time. The thing is that there may be many other places where this is assumed. Hmmm...
I propose this change: fix-mouse-move-bug.cs http://forum.world.st/file/n4829903/fix-mouse-move-bug.cs
It makes #wantsEveryMouseMove functional again and adds it to the EventHandler, too. It also duplicates the additional checks regarding mouse focus, submorphs, button down, etc.
Best, Marcel
-- View this message in context: http://forum.world.st/BUG-Automagic-scrolling-tp4829828p4829903.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
http://forum.world.st/The-Trunk-Morphic-mt-987-mcz-td4830105.html
Best, Marcel
-- View this message in context: http://forum.world.st/BUG-Automagic-scrolling-tp4829828p4830115.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
The color picker appears fine again too with this. Thanks Marcel!
On Wed, Jun 3, 2015 at 1:37 AM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
http://forum.world.st/The-Trunk-Morphic-mt-987-mcz-td4830105.html
Best, Marcel
-- View this message in context: http://forum.world.st/BUG-Automagic-scrolling-tp4829828p4830115.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
David T. Lewis -
karl ramberg -
marcel.taeumel