Re: [Pharo-project] Morphic replacement
Glad to be able to say: yes! Each object speaks in its own coordinate system, its parent already internalized the point. Suppose we have a click, announced by the mouse at a given point, given in Display coordinates.
From now on we go, from the display, to the view , to the scene, to the shape, and on each step the parent deals with a point in its own coordinate system, and passes on the internalized click to its children.
Views present a scene, consisting of shapes, at a given viewport of the display. Makes it a lot easier when you are programming the interaction of custom widgets, to always deal with local coordinates, and greatly simplifies the event handling code as well. On Fri, Nov 25, 2011 at 5:00 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
did you kill the absolute coordinates?
say yes please :)
Stef
On Nov 25, 2011, at 11:00 AM, Fernando Olivero wrote:
Dear all,
I've been working on a hole replacement of Morphic myself, because if was tired of fixing Morphic (or porting CUIS Morphic into Pharo), and found much more productive the approach of rewriting it from scratch.
excellent!
In my expierience, i was 100% more productive by not trying to be backward compatible with Morphic, Polymorph , etc.
I found it easier to  come up with a new set of widgets (EntryField, AutoCompletionEntryField, Button, Label, Column, Row, ScrollableColumns) from scratch. They are all fairly tested also.
Maybe it's time to move on, and develop from the ground up a Morphic-like successor, instead of fixing the current Morphic. There's no problem with preserving the current UI for all the apps that are out there, and provide a cleaner, simpler UI framework for the new apps.
Regarding the new "morphic", I only assume that i have a scalable canvas, and the vm's notifying me of the user events. On top of that i recreated a World, that can have multiple views. There's only one World at a given time. Views are presented within the world in a given viewport, and present a scene. Scene are were the shapes live in. No World as a subclass of PasteUpMorph, no globals such as World, ActiveWorld, Hand. ActiveHand, etcs..
The world has a mouse and a keyboard, which take care of events announced by the world. For example GMouse>>down: aDisplayPosition, would take care of transforming the display position into a world position, into a view position, into a scene position, and finally notifying the proper shape under the mouse that it has been clicked at a certain local position. GShape>>clickedAt: , GShape>>secondaryClickedAt:, etc.. No Events hierarchy, or the awful switch currently in HandMorph ( generateMouseEvent: or generateKeyboardEvent:).
I have a "Gaucho" system working now, Â with GShape (instead of Morphs), using the simple new layouts developed by Juan in CUIS, uniform usage of keybindings across the whole GShape hierarchy, amongst other goodies. It's still tailored to be a Morphic replacement for Gaucho, so first i need to polish a few things prior to releasing it.
For example, i'm going to ditch my current scalable canvas implementation, in favor of Athens.
Hope that very soon i can provide more details, but my plans are to release it as part of the next Gaucho version, to provide a working example.
Fernando
On 25 November 2011 17:22, Fernando Olivero <fernando.olivero@usi.ch> wrote:
Glad to be able to say: yes!
Each object speaks in its own coordinate system, its parent already internalized the point.
Suppose we have a click, announced by the mouse at a given point, given in Display coordinates.
From now on we go, from the display, to the view , to the scene, to the shape, and on each step the parent deals with a point in its own coordinate system, and passes on the internalized click to its children.
Views present a scene, consisting of shapes, at a given viewport of the display.
Makes it a lot easier when you are programming the interaction of custom widgets, to always deal with local coordinates, and greatly simplifies the event handling code as well.
ideed. i don't understand, why original Morphic authors decided to use absolute coordinates for morphs
On Fri, Nov 25, 2011 at 5:00 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
did you kill the absolute coordinates?
say yes please :)
Stef
On Nov 25, 2011, at 11:00 AM, Fernando Olivero wrote:
Dear all,
I've been working on a hole replacement of Morphic myself, because if was tired of fixing Morphic (or porting CUIS Morphic into Pharo), and found much more productive the approach of rewriting it from scratch.
excellent!
In my expierience, i was 100% more productive by not trying to be backward compatible with Morphic, Polymorph , etc.
I found it easier to  come up with a new set of widgets (EntryField, AutoCompletionEntryField, Button, Label, Column, Row, ScrollableColumns) from scratch. They are all fairly tested also.
Maybe it's time to move on, and develop from the ground up a Morphic-like successor, instead of fixing the current Morphic. There's no problem with preserving the current UI for all the apps that are out there, and provide a cleaner, simpler UI framework for the new apps.
Regarding the new "morphic", I only assume that i have a scalable canvas, and the vm's notifying me of the user events. On top of that i recreated a World, that can have multiple views. There's only one World at a given time. Views are presented within the world in a given viewport, and present a scene. Scene are were the shapes live in. No World as a subclass of PasteUpMorph, no globals such as World, ActiveWorld, Hand. ActiveHand, etcs..
The world has a mouse and a keyboard, which take care of events announced by the world. For example GMouse>>down: aDisplayPosition, would take care of transforming the display position into a world position, into a view position, into a scene position, and finally notifying the proper shape under the mouse that it has been clicked at a certain local position. GShape>>clickedAt: , GShape>>secondaryClickedAt:, etc.. No Events hierarchy, or the awful switch currently in HandMorph ( generateMouseEvent: or generateKeyboardEvent:).
I have a "Gaucho" system working now, Â with GShape (instead of Morphs), using the simple new layouts developed by Juan in CUIS, uniform usage of keybindings across the whole GShape hierarchy, amongst other goodies. It's still tailored to be a Morphic replacement for Gaucho, so first i need to polish a few things prior to releasing it.
For example, i'm going to ditch my current scalable canvas implementation, in favor of Athens.
Hope that very soon i can provide more details, but my plans are to release it as part of the next Gaucho version, to provide a working example.
Fernando
-- Best regards, Igor Stasenko.
Benefit of doubt: I assume they used absolute coordinates in the belief that it would reduce the amount of translation of coordinates that would be needed??? Less benefit of doubt: they might have done it to make things easier on "end users." If that were their answer, I would respond with a long-standing life lesson: NEVER coddle the user; it always backfires. The user won't do anything with the code you mangled thinking you were going to help them, and you've just made life hard on the people they will have to hire to do things for them. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua@gmail.com] Sent: Friday, November 25, 2011 11:26 AM To: Pharo-project@lists.gforge.inria.fr; fernando.olivero@usi.ch Subject: Re: [Pharo-project] Morphic replacement On 25 November 2011 17:22, Fernando Olivero <fernando.olivero@usi.ch> wrote:
Glad to be able to say: yes!
Each object speaks in its own coordinate system, its parent already internalized the point.
Suppose we have a click, announced by the mouse at a given point, given in Display coordinates.
From now on we go, from the display, to the view , to the scene, to the shape, and on each step the parent deals with a point in its own coordinate system, and passes on the internalized click to its children.
Views present a scene, consisting of shapes, at a given viewport of the display.
Makes it a lot easier when you are programming the interaction of custom widgets, to always deal with local coordinates, and greatly simplifies the event handling code as well.
ideed. i don't understand, why original Morphic authors decided to use absolute coordinates for morphs
On Fri, Nov 25, 2011 at 5:00 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
did you kill the absolute coordinates?
say yes please :)
Stef
On Nov 25, 2011, at 11:00 AM, Fernando Olivero wrote:
Dear all,
I've been working on a hole replacement of Morphic myself, because if was tired of fixing Morphic (or porting CUIS Morphic into Pharo), and found much more productive the approach of rewriting it from scratch.
excellent!
In my expierience, i was 100% more productive by not trying to be backward compatible with Morphic, Polymorph , etc.
I found it easier to come up with a new set of widgets (EntryField, AutoCompletionEntryField, Button, Label, Column, Row, ScrollableColumns) from scratch. They are all fairly tested also.
Maybe it's time to move on, and develop from the ground up a Morphic-like successor, instead of fixing the current Morphic. There's no problem with preserving the current UI for all the apps that are out there, and provide a cleaner, simpler UI framework for the new apps.
Regarding the new "morphic", I only assume that i have a scalable canvas, and the vm's notifying me of the user events. On top of that i recreated a World, that can have multiple views. There's only one World at a given time. Views are presented within the world in a given viewport, and present a scene. Scene are were the shapes live in. No World as a subclass of PasteUpMorph, no globals such as World, ActiveWorld, Hand. ActiveHand, etcs..
The world has a mouse and a keyboard, which take care of events announced by the world. For example GMouse>>down: aDisplayPosition, would take care of transforming the display position into a world position, into a view position, into a scene position, and finally notifying the proper shape under the mouse that it has been clicked at a certain local position. GShape>>clickedAt: , GShape>>secondaryClickedAt:, etc.. No Events hierarchy, or the awful switch currently in HandMorph ( generateMouseEvent: or generateKeyboardEvent:).
I have a "Gaucho" system working now, with GShape (instead of Morphs), using the simple new layouts developed by Juan in CUIS, uniform usage of keybindings across the whole GShape hierarchy, amongst other goodies. It's still tailored to be a Morphic replacement for Gaucho, so first i need to polish a few things prior to releasing it.
For example, i'm going to ditch my current scalable canvas implementation, in favor of Athens.
Hope that very soon i can provide more details, but my plans are to release it as part of the next Gaucho version, to provide a working example.
Fernando
-- Best regards, Igor Stasenko.
I guess the absolute coordinates are kept in a cache or something? This is probably necessary when you want to redraw inner widget without redisplaying the nesting ones Alexandre Le 25 nov. 2011 à 13:22, Fernando Olivero <fernando.olivero@usi.ch> a écrit :
Glad to be able to say: yes!
Each object speaks in its own coordinate system, its parent already internalized the point.
Suppose we have a click, announced by the mouse at a given point, given in Display coordinates.
From now on we go, from the display, to the view , to the scene, to the shape, and on each step the parent deals with a point in its own coordinate system, and passes on the internalized click to its children.
Views present a scene, consisting of shapes, at a given viewport of the display.
Makes it a lot easier when you are programming the interaction of custom widgets, to always deal with local coordinates, and greatly simplifies the event handling code as well.
On Fri, Nov 25, 2011 at 5:00 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
did you kill the absolute coordinates?
say yes please :)
Stef
On Nov 25, 2011, at 11:00 AM, Fernando Olivero wrote:
Dear all,
I've been working on a hole replacement of Morphic myself, because if was tired of fixing Morphic (or porting CUIS Morphic into Pharo), and found much more productive the approach of rewriting it from scratch.
excellent!
In my expierience, i was 100% more productive by not trying to be backward compatible with Morphic, Polymorph , etc.
I found it easier to come up with a new set of widgets (EntryField, AutoCompletionEntryField, Button, Label, Column, Row, ScrollableColumns) from scratch. They are all fairly tested also.
Maybe it's time to move on, and develop from the ground up a Morphic-like successor, instead of fixing the current Morphic. There's no problem with preserving the current UI for all the apps that are out there, and provide a cleaner, simpler UI framework for the new apps.
Regarding the new "morphic", I only assume that i have a scalable canvas, and the vm's notifying me of the user events. On top of that i recreated a World, that can have multiple views. There's only one World at a given time. Views are presented within the world in a given viewport, and present a scene. Scene are were the shapes live in. No World as a subclass of PasteUpMorph, no globals such as World, ActiveWorld, Hand. ActiveHand, etcs..
The world has a mouse and a keyboard, which take care of events announced by the world. For example GMouse>>down: aDisplayPosition, would take care of transforming the display position into a world position, into a view position, into a scene position, and finally notifying the proper shape under the mouse that it has been clicked at a certain local position. GShape>>clickedAt: , GShape>>secondaryClickedAt:, etc.. No Events hierarchy, or the awful switch currently in HandMorph ( generateMouseEvent: or generateKeyboardEvent:).
I have a "Gaucho" system working now, with GShape (instead of Morphs), using the simple new layouts developed by Juan in CUIS, uniform usage of keybindings across the whole GShape hierarchy, amongst other goodies. It's still tailored to be a Morphic replacement for Gaucho, so first i need to polish a few things prior to releasing it.
For example, i'm going to ditch my current scalable canvas implementation, in favor of Athens.
Hope that very soon i can provide more details, but my plans are to release it as part of the next Gaucho version, to provide a working example.
Fernando
participants (4)
-
Alexandre Bergel -
Fernando Olivero -
Igor Stasenko -
Schwab,Wilhelm K