November 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Morphic replacement

by Schwab,Wilhelm K

+1 on moving to relative coordinates! ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Friday, November 25, 2011 11:00 AM To: Pharo-project(a)lists.gforge.inria.fr; fernando.olivero(a)usi.ch Subject: Re: [Pharo-project] Morphic replacement 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 >

Nov. 25, 2011

Re: [Pharo-project] Morphic replacement

by Igor Stasenko

On 25 November 2011 17:22, Fernando Olivero <fernando.olivero(a)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(a)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.

Nov. 25, 2011

Re: [Pharo-project] Morphic replacement

by Bernhard Pieber

Hi Fernando, This sounds very interesting! Do you have a rich text widget? ;-) Cheers, Bernhard Am 25.11.2011 um 11:00 schrieb Fernando Olivero: > 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. > > 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 >

Nov. 25, 2011

Re: [Pharo-project] Morphic replacement

by Fernando Olivero

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(a)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 >> > >

Nov. 25, 2011

Re: [Pharo-project] Building 32-bit Cairo library on Macs

by Igor Stasenko

Just to let you know: it works on Mac! I just loaded the code which Javier did for linux, changed path to library and it worked out of the box. all examples in [1] are working out of the box! So, now i can start wiring Cairo backend for Athens :) [1] http://squeaksource.com/NBCairo/ -- Best regards, Igor Stasenko.

Nov. 25, 2011

Re: [Pharo-project] VM Exit Value

by Igor Stasenko

On 25 November 2011 17:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > in the bug tracker please :) > done: http://code.google.com/p/pharo/issues/detail?id=5029 -- Best regards, Igor Stasenko.

Nov. 25, 2011

Re: [Pharo-project] VM Exit Value

by Igor Stasenko

Yes, it works! if i open image like that: ./results/NBCog.app/Contents/MacOS/NBCog ./image/generator.image ; echo $? and then do: Smalltalk quitPrimitive: 10 it prints: 10 On 25 November 2011 17:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > in the bug tracker please :) > > > On Nov 25, 2011, at 4:59 PM, Igor Stasenko wrote: > >> There is already support for that in platform-specific code. >> The function is >> sqInt ioExitWithErrorCode(int); >> >> >> so, the only thing which we need is to change the #primitiveQuit >> >> to see if there an extra argument to it, >> and then call >> that function instead of ioExit >> >> looks like easy to do. >> >> Btw, actually Cog VMs already doing that: >> >> primitiveQuit >> >> Â Â Â self ioExitWithErrorCode: (argumentCount = 1 ifTrue: [objectMemory >> integerValueOf: self stackTop] ifFalse: [0]) >> >> so.. you need only 1 thing: >> >> add one more method to Smalltalk: >> >> quitPrimitive: exitCode >> Â Â Â "Primitive. Exit to another operating system on the host machine, if one >> Â Â Â exists. All state changes in the object space since the last snapshot are lost. >> Â Â Â Essential. See Object documentation whatIsAPrimitive." >> >> Â Â Â <primitive: 113> >> Â Â Â self primitiveFailed >> >> so you can use it right now. >> >> -- >> Best regards, >> Igor Stasenko. >> > > > -- Best regards, Igor Stasenko.

Nov. 25, 2011

Re: [Pharo-project] VM Exit Value

by StÃ©phane Ducasse

in the bug tracker please :) On Nov 25, 2011, at 4:59 PM, Igor Stasenko wrote: > There is already support for that in platform-specific code. > The function is > sqInt ioExitWithErrorCode(int); > > > so, the only thing which we need is to change the #primitiveQuit > > to see if there an extra argument to it, > and then call > that function instead of ioExit > > looks like easy to do. > > Btw, actually Cog VMs already doing that: > > primitiveQuit > > self ioExitWithErrorCode: (argumentCount = 1 ifTrue: [objectMemory > integerValueOf: self stackTop] ifFalse: [0]) > > so.. you need only 1 thing: > > add one more method to Smalltalk: > > quitPrimitive: exitCode > "Primitive. Exit to another operating system on the host machine, if one > exists. All state changes in the object space since the last snapshot are lost. > Essential. See Object documentation whatIsAPrimitive." > > <primitive: 113> > self primitiveFailed > > so you can use it right now. > > -- > Best regards, > Igor Stasenko. >

Nov. 25, 2011

Re: [Pharo-project] Issue 5028: failing MCPackageManager initialization

by StÃ©phane Ducasse

No may be just a mistake. > http://code.google.com/p/pharo/issues/detail?id=5028 > > MCPackageManager class >> #initialize contains unimplemented call of > #unregisterForNotifications so Monticello cannot be loaded to a fresh > image. This method is no more present in the image. > > Does anyone know why it was removed? It seems to be related to same > changes done by Stef. > > -- Pavel >

Nov. 25, 2011

Re: [Pharo-project] Morphic replacement

by StÃ©phane Ducasse

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 >

Nov. 25, 2011