- Pharo-dev - lists.pharo.org

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

by John M McIntosh

You can remove that from the menu using the os-x mac menu api that is used to modify the menu at startup time, so at startup time an additonal step is needed. It's left there because some people wanted a way to quit the image without any squeak image involvement, it could of course be made a preference. As for the quit and prompt there is a change notification that is broadcast when a method is changed I think it's register SystemChangeNotifier uniqueInstance notify: self ofSystemChangesOfItem: #method change: #Added using: #modified:; notify: self ofSystemChangesOfItem: #method change: #Modified using: #modified:; notify: self ofSystemChangesOfItem: #method change: #Removed using: #modified: But ensuring you have all the cases would be debatable. On 11-Jun-09, at 3:21 AM, 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 -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

June 11, 2009

Re: [Pharo-project] multiple native windows

by Damien Cassou

On Thu, Jun 11, 2009 at 4:38 PM, Michael Rueger<m.rueger(a)acm.org> wrote: > Also the GTK bindings and Newspeak use native windows (I > think?). Newspeak uses either native or morphic windows, depending on the wishes of the user. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 11, 2009

Re: [Pharo-project] multiple native windows

by Michael Rueger

Steve Wirts wrote: > Besides programming effort, is there a reason why squeak/pharo shouldn't > consider going to a GUI model that includes real multiple native windows? Yes, Morphic ;-) Would be pretty hard to make it work with multiple windows. At least that's the consensus... The infrastructure is basically in place and has been used for prototypes. Also the GTK bindings and Newspeak use native windows (I think?). Michael

June 11, 2009

Re: [Pharo-project] multiple native windows

by StÃ©phane Ducasse

> 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 would love to have that we should have a look at ffenestria and fix it. So this is just that somebody should do it. > 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 Stef

June 11, 2009

[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