It should now be okay. Please update to
Mondrian-Alexandre_Bergel.355 Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Cool, popups work much better than before, thanks a lot! I however got a DNU at some point because ActiveHand was nil at some point. I think that you are forking in the wrong place: your code lets the drawing of the popup be in a separate thread, while I would have the entire process of waiting for the delay time and then drawing be in a separate thread. Just an extra pair of [] does that, see code below. As far as I can analyze the code it should not produce concurrency issues. (Although I prefer the conceptually clean solution I detailed last week) I have played around with this for some time and it works fine. But of course for concurrent code this is not a guarantee ... popupView: aBlock delay: ms "open a popup text when the mouse enter a node" "Yeah, this method is a bit scary" self unsubscribeForEvent: MOMouseEnter. self unsubscribeForEvent: MOMouseLeave. self subscribe: MOMouseEnter do: [:ann | (ann hasElement and: [(ann element isKindOf: MORoot) not]) ifTrue: [ "Note extra [" [ | oldPosition view newCanvas relativePosition | [oldPosition := ActiveHand position. (Delay forMilliseconds: ms) wait. "we compute the relative position since ActiveHand return an absolute location" relativePosition := ann position - oldPosition + ActiveHand position. "We check if we are in the same node, if yes, then we evaluate the view" (ann root notNil and: [(ann root elementAt: relativePosition) == ann current]) ifTrue: [ view := MOViewRenderer new. aBlock value: ann element model value: view. newCanvas := MOPopup showView: view. ann element popup: newCanvas. ] ]] fork. "note extra ] before fork" ] ifFalse: [ann element popup ifNotNilDo: [:v | v delete]. MOPopup remove] ]. self subscribe: MOMouseLeave do: [:ann | ann element popup ifNotNilDo: [:v | v delete]. MOPopup remove ]. On 26 Jan 2010, at 21:37, Alexandre Bergel wrote: > It should now be okay. Please update to > > Mondrian-Alexandre_Bergel.355 > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Johan Fabry [hidden email] - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
<slaps hand to face>
Sorry guys, forget this code, it does not work (although theoretically it should ;-) ). I did not reopen the mondrian view when I tested this version, so I was still testing Alex's version. It's a pity that the dynamism of ST & method recompilation stops when treating with Mondrian. I'm still not used to that :-( No time to figure the concurrency issue out in more detail though, sorry for that ... On 27 Jan 2010, at 11:51, Johan Fabry wrote: > As far as I can analyze the code it should not produce concurrency > issues. (Although I prefer the conceptually clean solution I > detailed last week) I have played around with this for some time and > it works fine. But of course for concurrent code this is not a > guarantee ... -- Johan Fabry [hidden email] - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Free forum by Nabble | Edit this page |