Hi Guillermo. When you combine these triggers with ads (as in your example), I see an analogy with the model of qt ui, see: http://qt-project.org/doc/qt-4.8/signalsandslots.html
In effect: "A signal is emitted when a particular event occurs." -> A Announcement is send when a particular event (trigger) occurs. " Qt's widgets have many predefined signals, but we can always subclass widgets to add our own signals to them" -> Morphic widgets have many predefined triggers, but we can always subclass widgets to add our own triggers to them. "A slot is a function that is called in response to a particular signal. " -> A AnnouncementSubscription is ? that is used in response to a particular announcement. It's a mechanic for decouple between sender and interested in event occurrence. As you surely know Morphic Designer follows basic ideas of the QtDesigner: https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/designer Look at doc here (I never see code of this project), this approach not use announcement framework, but a signal implementation: https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/signals Regards. 2012/4/28 Guillermo Polito <[email protected]> > > > On Sat, Apr 28, 2012 at 1:13 PM, Denis Kudriashov <[email protected]>wrote: > >> Hello. >> >> >> 2012/4/27 Guillermo Polito <[email protected]> >> >>> onShow >>> onDelete >>> onKeyUp >>> onKeyPress >>> onKeyDown >>> onClick >>> onMouseDown >>> onMouseUp >>> onDoubleClick >>> onDragged >>> onDropped >>> onMove? >>> onResize? >>> >>> For all containers >>> onChildAdded >>> onChildRemoved >>> >> >> Maybe this is only way for adding such behaviour in current Morphic >> design. >> > > Starting from a safe point is important when you have a mess :3. > > >> And such approach is most common solution in mainstream UI systems. >> > > I'm for sure influenced by other technologies :). But the changed-updated > mechanism of Morphic makes everything ugly. I just want to make explicit > the events morphs expose to the clients. > > >> But I always feel big smell in such design decisions. >> I am sure more clever solution can be implemented with another Morphic >> design. >> > > What I'd like from a widget is: > - binding values to model properties > - event dispatching on user interaction, so I can register to them > > And containers with nice layouting > > the PluggableXXXMorph have some kind of that stuff modeled, but in the > list of widgets I found, not all of them are PluggableXXX, and there are > some duplicated morphs, and they are spread all over the Morph and Polmorph > package. > > I send the mail to the mailing-list to open a discussion, so I'd like to > know your point of view :). > > Guille >
