Stéphane Ducasse wrote:
JuanI was looking a bit at triggerEvent: and I seein pharo and probably in squeak code like the following one mouseUp: anEvent "Change the cursor back to normal if necessary and change the color back to normal." self canResizeColumn ifFalse: [^ self]. (self bounds containsPoint: anEvent cursorPoint) ifFalse: [anEvent hand showTemporaryCursor: nil]. self class fastSplitterResize ifTrue: [self updateFromEvent: anEvent]. traceMorph ifNotNil: [traceMorph delete. traceMorph := nil]. self adoptPaneColor: self paneColor. self triggerEvent: #mouseUp So how does it fit your model? Stef
Morphic gives a lot of freedom on what you can do. For example, you can ask a morph to be notified when the morph itself gets a mouse event. In Cuis and Squeak you can also do that.
My "pattern for GUI programming" is implemented in the new LightWidget hierarchy. LightWidgets do not generate events like Morphs do. That's why it is a separate root class, as LightWidget is not subclass of Morph. It is to be coded in a different style.
Morphic in Cuis does _not_ follow the "pattern for GUI programming". I hope, someday, to be able to use these rules for Morphic 3. This means that programming in Morphic 3 would be done like with LightWidgets and not like with Morphs. But Morphic 3 is far from mature enough to do this.
This programming style could also be adopted by Pharo, either using Morphic or "SimpleMorphic" from Cuis. But this is not done. It would be a great project, though.
Cheers, Juan Vuletich _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
