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 <[email protected]> wrote:

> 
> 
> 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

Reply via email to