Status: New Owner: ---- CC: alexandr...@gmail.com Labels: Type-Defect Priority-High Component-Mondrian Milestone-4.6
New issue 698 by tudor.gi...@gmail.com: Mondrian does not properly raise MOElementSelection http://code.google.com/p/moose-technology/issues/detail?id=698
When in Glamour, often when selecting a Mondrian element does not populate the selection because the MOCanvas does not raise MOElementSelection.
The reason for this seems to be a race condition due to changes in the announcement framework. In the new announcement framework from Pharo 1.3, the order of announcements is not guaranteed.
The issue seems to be due to the logic of the announcement:
MOCanvas>>mouseUp: .. (lastEnteredGraphElement isNil not and: [ (lastEnteredGraphElement class ~~ MORoot and: [ lastEnteredGraphElement isNotSelected ])]) ifTrue: [ selectionEvent := MOElementSelection event: anEvent on: lastEnteredGraphElement. anEvent commandKeyPressed ifTrue: [ selectionEvent setAsMultiple ]. self announce: selectionEvent. anEvent wasHandled: true. ^ self ].
Sometimes, "lastEnteredGraphElement isNotSelected" returns false because somehow the element gets selected beforehand. This is most likely related to the fact that the selection of a node actually happens by handling the same MOElementSelection announcement:
MOCanvas>>announce: anAnnouncement ... anAnnouncement element isNil ifFalse: [ anAnnouncement element announcer announce: anAnnouncement ]. self announcer announce: anAnnouncement.
MOViewRenderer>>setUsefulHandlersForNodes ... self interaction on: MOElementSelection do: [:ann | ann isUnique ifTrue: [ self root allSelectedNodes do: [ :node | node deselect; announce: (MOElementDeselection new) ] ]. ann element select. self updateWindow ].
Comment #1 on issue 698 by alexandr...@gmail.com: Mondrian does not properly raise MOElementSelection http://code.google.com/p/moose-technology/issues/detail?id=698
Any idea how I can reproduce the problem? Best would be to have a yellow test
Comment #2 on issue 698 by tu...@tudorgirba.com: Mondrian does not properly raise MOElementSelection http://code.google.com/p/moose-technology/issues/detail?id=698
I do not know how to write the test case.
To reproduce it: - open a MoosePanel - select a group of classes - select the system complexity tab - select a couple of classes. You will see that in many cases, the figure gets selected and it usually moves, but the next pane is not updated. Sometimes, it works though, that is why you have to click on multiple classes to see the problem.
Comment #3 on issue 698 by tudor.gi...@gmail.com: Mondrian does not properly raise MOElementSelection http://code.google.com/p/moose-technology/issues/detail?id=698
This is an important issue for 4.6. Alex, do you have time to look into it?
Comment #4 on issue 698 by alexandr...@gmail.com: Mondrian does not properly raise MOElementSelection http://code.google.com/p/moose-technology/issues/detail?id=698
I will have a look at it. But it may not be easy to fix this. I will work on it asap even if several deadlines are approaching. I will let the mailing list know about my progresses
Comment #5 on issue 698 by alexandr...@gmail.com: Mondrian does not properly raise MOElementSelection http://code.google.com/p/moose-technology/issues/detail?id=698
This is not reproducible in Pharo 1.4. Apparently, the problem comes from a shift by -1@0 when I click (it goes through MOCanvas>>mouseOver:) Really weird behavior.
Comment #6 on issue 698 by alexandr...@gmail.com: Mondrian does not properly raise MOElementSelection http://code.google.com/p/moose-technology/issues/detail?id=698
Is this problem still around?
Comment #7 on issue 698 by tudor.gi...@gmail.com: Mondrian does not properly raise MOElementSelection http://code.google.com/p/moose-technology/issues/detail?id=698
The problem is still around with the Jenkins VM, but works fine with the Elliot's Cog VM.
Comment #8 on issue 698 by stephane...@gmail.com: Mondrian does not properly raise MOElementSelection http://code.google.com/p/moose-technology/issues/detail?id=698
did you check the event that is generated? If you look in eventModel on Squeak source, you will see that there is listener that print event on the transcript now since this is VM code and you will not see anything in the image. So bad idea. Did you contact esteban?
Hi Esteban,
We have a serious problem with Mondrian, and we believe this comes from the way events are handled by the virtual machine. When drag and dropping a morph, it happens that the morph is dragged by 1 pixel to the left. As a short test, do a "Morph new openInWorld", grab the morph and when you release it by pressing the left mouse button, it moves by 1 pixel.
The problem is still around with the Jenkins VM (CogVM), but works fine with the Elliot's Cog VM.
Any idea where this comes from?
Cheers, Alexandre
On 4 Oct 2011, at 02:44, moose-technology@googlecode.com wrote:
Comment #8 on issue 698 by stephane...@gmail.com: Mondrian does not properly raise MOElementSelection http://code.google.com/p/moose-technology/issues/detail?id=698
did you check the event that is generated? If you look in eventModel on Squeak source, you will see that there is listener that print event on the transcript now since this is VM code and you will not see anything in the image. So bad idea. Did you contact esteban?
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Alex, I don't understand well the problem, or I can not reproduce it... I'm doing what you say and I don't see a problem there. Said so... carbon and cocoa event handling procedures are complete different, so... yes, it is possible that there are some glitch somewhere... if you can provide me some more info, I can continue digging into it.
cheers, Esteban
El 04/10/2011, a las 8:37a.m., Alexandre Bergel escribió:
Hi Esteban,
We have a serious problem with Mondrian, and we believe this comes from the way events are handled by the virtual machine. When drag and dropping a morph, it happens that the morph is dragged by 1 pixel to the left. As a short test, do a "Morph new openInWorld", grab the morph and when you release it by pressing the left mouse button, it moves by 1 pixel.
The problem is still around with the Jenkins VM (CogVM), but works fine with the Elliot's Cog VM.
Any idea where this comes from?
Cheers, Alexandre
On 4 Oct 2011, at 02:44, moose-technology@googlecode.com wrote:
Comment #8 on issue 698 by stephane...@gmail.com: Mondrian does not properly raise MOElementSelection http://code.google.com/p/moose-technology/issues/detail?id=698
did you check the event that is generated? If you look in eventModel on Squeak source, you will see that there is listener that print event on the transcript now since this is VM code and you will not see anything in the image. So bad idea. Did you contact esteban?
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
It is indeed a bit erratic. At the latest, I can show it to you first hand at Smalltalks.
Cheers, Doru
On 4 Oct 2011, at 21:08, Esteban Lorenzano wrote:
Hi Alex, I don't understand well the problem, or I can not reproduce it... I'm doing what you say and I don't see a problem there. Said so... carbon and cocoa event handling procedures are complete different, so... yes, it is possible that there are some glitch somewhere... if you can provide me some more info, I can continue digging into it.
cheers, Esteban
El 04/10/2011, a las 8:37a.m., Alexandre Bergel escribió:
Hi Esteban,
We have a serious problem with Mondrian, and we believe this comes from the way events are handled by the virtual machine. When drag and dropping a morph, it happens that the morph is dragged by 1 pixel to the left. As a short test, do a "Morph new openInWorld", grab the morph and when you release it by pressing the left mouse button, it moves by 1 pixel.
The problem is still around with the Jenkins VM (CogVM), but works fine with the Elliot's Cog VM.
Any idea where this comes from?
Cheers, Alexandre
On 4 Oct 2011, at 02:44, moose-technology@googlecode.com wrote:
Comment #8 on issue 698 by stephane...@gmail.com: Mondrian does not properly raise MOElementSelection http://code.google.com/p/moose-technology/issues/detail?id=698
did you check the event that is generated? If you look in eventModel on Squeak source, you will see that there is listener that print event on the transcript now since this is VM code and you will not see anything in the image. So bad idea. Did you contact esteban?
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing should have the right to be different."
Updates: Labels: -Milestone-4.6 Milestone-4.7
Comment #9 on issue 698 by tudor.gi...@gmail.com: Mondrian does not properly raise MOElementSelection http://code.google.com/p/moose-technology/issues/detail?id=698
(No comment was entered for this change.)
Updates: Labels: -Milestone-4.7
Comment #10 on issue 698 by tudor.gi...@gmail.com: Mondrian does not properly raise MOElementSelection http://code.google.com/p/moose-technology/issues/detail?id=698
I have the feeling we will not fix this issue, so I am removing the 4.7 tag.
Comment #11 on issue 698 by alexandr...@gmail.com: Mondrian does not properly raise MOElementSelection http://code.google.com/p/moose-technology/issues/detail?id=698
We should try to move to Roassal.
Updates: Status: WontFix
Comment #12 on issue 698 by alexandr...@gmail.com: Mondrian does not properly raise MOElementSelection http://code.google.com/p/moose-technology/issues/detail?id=698
(No comment was entered for this change.)
-
Alexandre Bergel -
Esteban Lorenzano -
moose-technology＠googlecode.com -
Tudor Girba