[Pharo-project] Adding hooks for well known events in morphic
I've made up a list with all the useful morphic widget I've found in a alpha alpha alpha 2.0 image. I'd like to put in those widgets empty hooks like: Morph>>triggerOnShow "hook" for common events widgets provide usually in MVC frameworks. That means *not changing the whole interface nor refactoring everything*. *Just adding the hooks*. What we were talking with Mariano (I hate you for putting ideas in my head) today in the train was to add those empty hooks and put senders for them, what should be easy. This way we can start to homogenize morphic a bit. Most likely, in a not so far future, those empty hooks could be replaced by something like: Morph>>triggerOnShow self announcer announce: (MorphShowAnnouncement show: self) Now, here is a list of the most important widgets i've found (I could've missed some) and events they should trigger. I'm not taking into account new multitouch interfaces and stuff. For all widgets onShow onDelete onKeyUp onKeyPress onKeyDown onClick onMouseDown onMouseUp onDoubleClick onDragged onDropped onMove? onResize? For all containers onChildAdded onChildRemoved "Widgets" Check/Radio -> CheckboxButtonMorph/SimpleSwitchMorph onSelectionChanged List/Grids -> PluggableListMorph/PluggableMultiColumnListMorph/LazyListMorph/MulticolumnLazyListMorph onSelectionChanged Button -> PluggableButtonMorph/SimpleButtonMorph/MultistateButtonMorph onClick Label -> LabelMorph/FuzzyLabelMorph /MultistateLabelMorph Progress Bar-> SystemProgressBarMorph Slider -> Slider/PluggableSliderMorph onSelectionChanged Text handling -> TextMorph/PluggableTextMorph onSelectionChanged Field Handling -> PluggableTextFieldMorph/PluggableTextEditorMorph Tree -> MorphTreeMorph onSelectionChanged onExpandItem onCollapseItem Combo box -> DropListMorph/EditableDropListMorph /SearchMorph/MorphDropListMorph onSelectionChanged Menues -> MenuMorph + friends onClick (for menu item probably) Image -> ImageMorph/ImagePreviewMorph Diff -> DiffMorph Color Presenter -> ColorPresenterMorph Color chooser -> ColorChooserMorph/HSVColorSelectorMorph / SVColorSelectorMorph onSelectionChanged Task var -> TaskbarMorph "Containers" ScrollPane Windows -> SystemWindow/PluggableSystemWindow /StandardWindow Dialog window -> DialogWindow & (lots of) subclasses Panel -> PanelMorph & subclasses / PluggablePanelMorph Tabs -> TabGroupMorph (Other Tab stuff -> PluggableTabBarMorph + PluggableTabButtonMorph ) onSelectionChanged Guille
Hello. 2012/4/27 Guillermo Polito <guillermopolito@gmail.com>
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. And such approach is most common solution in mainstream UI systems. But I always feel big smell in such design decisions. I am sure more clever solution can be implemented with another Morphic design.
On Sat, Apr 28, 2012 at 1:13 PM, Denis Kudriashov <dionisiydk@gmail.com>wrote:
Hello.
2012/4/27 Guillermo Polito <guillermopolito@gmail.com>
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
What about the stepping behaviour? Is the plan to remove that as well? I've got the hunch that stepping should only be restricted to special worlds. Otherwise you get a lot of behaviour, and complexity, that you don't need in a more traditional UI. My 2 cents... - Francisco On 28 Apr 2012, at 12:44, Guillermo Polito <guillermopolito@gmail.com> wrote:
On Sat, Apr 28, 2012 at 1:13 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote: Hello.
2012/4/27 Guillermo Polito <guillermopolito@gmail.com> 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
2012/4/28 Francisco Garau <francisco.garau@gmail.com>
What about the stepping behaviour? Is the plan to remove that as well?
I've got the hunch that stepping should only be restricted to special worlds. Otherwise you get a lot of behaviour, and complexity, that you don't need in a more traditional UI.
But now stepping behavior is only way for doing animation (like smooth scrolling)
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/... 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/... Regards. 2012/4/28 Guillermo Polito <guillermopolito@gmail.com>
On Sat, Apr 28, 2012 at 1:13 PM, Denis Kudriashov <dionisiydk@gmail.com>wrote:
Hello.
2012/4/27 Guillermo Polito <guillermopolito@gmail.com>
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
On Apr 28, 2012, at 2:39 PM, Gastón Dall' Oglio wrote:
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/...
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/...
I do not see the difference between signals and event. And yes we look at the code, it is not a really good idea to use thisContext for every little notifications.
2012/5/2 Stéphane Ducasse <stephane.ducasse@inria.fr>
I do not see the difference between signals and event.
For that reason, I meant about possibility of reuse this existing implementation, if it was useful for your objectives of course.
And yes we look at the code, it is not a really good idea to use thisContext for every little notifications.
I see, that is not good :) Maybe that explained the slow result in the benchmark at the below table in that page (Signals doc), compared to Announcement. Regards
Indeed rationalizing the hooks and removing the changed/update mechanism would be good. On Apr 27, 2012, at 8:58 PM, Guillermo Polito wrote:
I've made up a list with all the useful morphic widget I've found in a alpha alpha alpha 2.0 image. I'd like to put in those widgets empty hooks like:
Morph>>triggerOnShow "hook"
for common events widgets provide usually in MVC frameworks. That means not changing the whole interface nor refactoring everything. Just adding the hooks. What we were talking with Mariano (I hate you for putting ideas in my head) today in the train was to add those empty hooks and put senders for them, what should be easy. This way we can start to homogenize morphic a bit.
Most likely, in a not so far future, those empty hooks could be replaced by something like:
Morph>>triggerOnShow self announcer announce: (MorphShowAnnouncement show: self)
Now, here is a list of the most important widgets i've found (I could've missed some) and events they should trigger. I'm not taking into account new multitouch interfaces and stuff.
For all widgets onShow onDelete onKeyUp onKeyPress onKeyDown onClick onMouseDown onMouseUp onDoubleClick onDragged onDropped onMove? onResize?
For all containers onChildAdded onChildRemoved
"Widgets"
Check/Radio -> CheckboxButtonMorph/SimpleSwitchMorph onSelectionChanged
List/Grids -> PluggableListMorph/PluggableMultiColumnListMorph/LazyListMorph/MulticolumnLazyListMorph onSelectionChanged
Button -> PluggableButtonMorph/SimpleButtonMorph/MultistateButtonMorph onClick
Label -> LabelMorph/FuzzyLabelMorph /MultistateLabelMorph
Progress Bar-> SystemProgressBarMorph
Slider -> Slider/PluggableSliderMorph onSelectionChanged
Text handling -> TextMorph/PluggableTextMorph onSelectionChanged
Field Handling -> PluggableTextFieldMorph/PluggableTextEditorMorph
Tree -> MorphTreeMorph onSelectionChanged onExpandItem onCollapseItem
Combo box -> DropListMorph/EditableDropListMorph /SearchMorph/MorphDropListMorph onSelectionChanged
Menues -> MenuMorph + friends onClick (for menu item probably)
Image -> ImageMorph/ImagePreviewMorph
Diff -> DiffMorph
Color Presenter -> ColorPresenterMorph
Color chooser -> ColorChooserMorph/HSVColorSelectorMorph / SVColorSelectorMorph onSelectionChanged
Task var -> TaskbarMorph
"Containers" ScrollPane Windows -> SystemWindow/PluggableSystemWindow /StandardWindow Dialog window -> DialogWindow & (lots of) subclasses Panel -> PanelMorph & subclasses / PluggablePanelMorph
Tabs -> TabGroupMorph (Other Tab stuff -> PluggableTabBarMorph + PluggableTabButtonMorph ) onSelectionChanged
Guille
participants (5)
-
Denis Kudriashov -
Francisco Garau -
Gastón Dall' Oglio -
Guillermo Polito -
Stéphane Ducasse