thanks for the information. On Sep 19, 2010, at 3:38 PM, Juan Vuletich wrote:
> Stéphane Ducasse wrote: >> Juan >> >> I 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
