June 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] multiple native windows

by Steve Wirts

Besides programming effort, is there a reason why squeak/pharo shouldn't consider going to a GUI model that includes real multiple native windows? I'm not a c/c++ programmer and wouldn't know where to begin with that piece, but inside of smalltalk it seems it wouldn't be all that difficult of a refactoring. I only bring this up as this would put pharo/squeak more in line with many other conventional languages (with respect to user interfaces), and get it "back in the game" so to speak for when technologies are being considered for business solutions. You could include in this 1) Native support for drag and drop and 2) support for embedded native controls. Something like SWT and Jide now both support. Sorry if I've overlooked something with this and the con is obvious. thanks sw

June 11, 2009

Re: [Pharo-project] a plea for "save and quit"

by dmason＠mason-rose.ca

My vote goes for: -'Save ...' -> 'Save and Quit', 'Save', 'Save as ...' -'----' -'Quit' with 'Save as ...' defaulting to new version. Instead of the delimiter which doesn't actually leave much space, 'Save ...' could move near the beginning of the menu - maybe before Tools, and leave 'Quit' at the end. ../Dave

June 11, 2009

Re: [Pharo-project] a plea for "save and quit"

by Oscar Nierstrasz

Hm. Isn't it as simple as this? Author initialsPerSe isEmpty Or is that too naive? ;-) - on On Jun 11, 2009, at 14:12, Michael Roberts wrote: > one of the challenges is how does the image know it has any active > changes? it's not as easy as editing a document say. This could be an > interesting technical challenge. Ideally you would ask for 'quit' and > if there are no changes, it would not save. if there were it would > prompt you to save them.

June 11, 2009

Re: [Pharo-project] a plea for "save and quit"

by Alain Plantec

Tudor Girba a Ã©crit : > "Save" > "Save as..." > "Save and quit" > ----- > "Quit Hi all, I like this simple proposition. We still have 'recover lost changes' in the case of unwanted quit without saving. alain

June 11, 2009

Re: [Pharo-project] a plea for "save and quit"

by Michael Roberts

I agree with Oscar. one of the challenges is how does the image know it has any active changes? it's not as easy as editing a document say. This could be an interesting technical challenge. Ideally you would ask for 'quit' and if there are no changes, it would not save. if there were it would prompt you to save them. However, in absence of such sophistication in our object world I would at least lay the menu out a little more safely. thanks Mike On Thu, Jun 11, 2009 at 12:22 PM, Oscar Nierstrasz<oscar(a)iam.unibe.ch> wrote: > > No. > > Sometimes we want: > - Save and Quit > and sometimes we want > - Quit without saving > > but they should not be located where we can too easily click the wrong > thing. > > They should not be next to each other, and they should not be in the > default location of a File Menu. > > I know, I have done this too, more than once. > > - on > > On Jun 11, 2009, at 13:11, StÃ©phane Ducasse wrote: > >> you mean >> >> quit >> Â Â Â should be always >> Â Â Â asking to save? >> >> >> On Jun 11, 2009, at 12:21 PM, Michael Roberts wrote: >> >>> whilst we are debating 'quit' can we move 'Quit do not save' so it is >>> not the first item in the native OS X File menu. Â I have accidentally >>> clicked it a few times and it is a disaster. Â It is also quite >>> different from platform semantics where are you would normally be >>> prompted if a quit would discard changes. Â It should be at the bottom >>> of the menu at the very least. Â Dare I ask if we need it at all... >>> >>> thanks >>> Mike >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 11, 2009

Re: [Pharo-project] a plea for "save and quit"

by Oscar Nierstrasz

No. Sometimes we want: - Save and Quit and sometimes we want - Quit without saving but they should not be located where we can too easily click the wrong thing. They should not be next to each other, and they should not be in the default location of a File Menu. I know, I have done this too, more than once. - on On Jun 11, 2009, at 13:11, StÃ©phane Ducasse wrote: > you mean > > quit > should be always > asking to save? > > > On Jun 11, 2009, at 12:21 PM, Michael Roberts wrote: > >> whilst we are debating 'quit' can we move 'Quit do not save' so it is >> not the first item in the native OS X File menu. I have accidentally >> clicked it a few times and it is a disaster. It is also quite >> different from platform semantics where are you would normally be >> prompted if a quit would discard changes. It should be at the bottom >> of the menu at the very least. Dare I ask if we need it at all... >> >> thanks >> Mike >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 11, 2009

Re: [Pharo-project] a plea for "save and quit"

by StÃ©phane Ducasse

you mean quit should be always asking to save? On Jun 11, 2009, at 12:21 PM, Michael Roberts wrote: > whilst we are debating 'quit' can we move 'Quit do not save' so it is > not the first item in the native OS X File menu. I have accidentally > clicked it a few times and it is a disaster. It is also quite > different from platform semantics where are you would normally be > prompted if a quit would discard changes. It should be at the bottom > of the menu at the very least. Dare I ask if we need it at all... > > thanks > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 11, 2009

Re: [Pharo-project] a plea for "save and quit"

by Michael Roberts

whilst we are debating 'quit' can we move 'Quit do not save' so it is not the first item in the native OS X File menu. I have accidentally clicked it a few times and it is a disaster. It is also quite different from platform semantics where are you would normally be prompted if a quit would discard changes. It should be at the bottom of the menu at the very least. Dare I ask if we need it at all... thanks Mike

June 11, 2009

Re: [Pharo-project] #IdentityIncludes: for FloatArray

by Nicolas Cellier

FloatArray is a raw array of bits interpreted as single precision (32 bits) floats. It does not contain any object pointer, only the content (value). At each access #at: will create a new Float (64 bits). So you have (self at: 1) ~~ (self at: 1). Does that explain? Nicolas 2009/6/11 Cyrille Delaunay <cyrille.delaunay(a)etudiant.univ-lille1.fr>: > > > try to inspect: > (FloatArray new:1)at: 1 put: 2.5 ; yourself > and print: > self identityIncludes: self anyOne > > It returns false. > Is it a 'normal' comportment ? > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 11, 2009

[Pharo-project] #IdentityIncludes: for FloatArray

by Cyrille Delaunay

try to inspect: (FloatArray new:1)at: 1 put: 2.5 ; yourself and print: self identityIncludes: self anyOne It returns false. Is it a 'normal' comportment ?

June 11, 2009