this is why it was removed. in fact there is no quit On Jun 10, 2009, at 1:46 PM, Henrik Johansen wrote:

IIRC, you get the option to save whenever you try to quit. So save and quit didn't really make sense, as it'd save, then ask you if you wanted to save again before actually quitting...

Cheers, Henry

Oscar Nierstrasz skrev:

...

Hi Folks,

Is there any reason why "save and quit" is commented out of the world menu? It is what I want to do 90% of the time.

Would be nice to have it back by default.

- on

TheWorldMenu>>buildWorldMenu "Build the menu that is put up when the screen-desktop is clicked on" | menu | ... self fillIn: menu from: { nil. ... "{'save and quit'. {self. #saveAndQuit}. 'save the current image on disk, and quit out of Squeak.'}." {'quit'. {self. #quitSession}. 'quit out of Squeak.'} }. ^ menu

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oscar Nierstrasz wrote:

Nope.

If I uncomment it, it works exactly as I want, which is to save and quit without any further prompting.

+10, I hate that this was removed and always go and put it back in. I don't want to go through a two step process every time. -- Ramon Leon http://onsmalltalk.com

Stéphane Ducasse wrote:

well there is tension between long menus and short menus. and if we have already three items just to save we will end up been squeakish. So except if there is a huge pression or a cool argument we would like to keep save/quit and not have save/quit/save and quit

we could move save as and save as version into a save as sub-menu. that would leave save save as quit as choices. And we could actually remove quit ;-) as it is already handled by closing the window or quitting from the mac menu. Michael

What about auto-adaptative menus learning your habits. X most used items on top. Y often used items following. Every other less used items in submenus. Of course, a logical order could be preserved among the Y often used items. That's already the spirit of Pharo world menu, except this is a bit static for a dynamic language! Nicolas 2009/6/10 Antoine Marot <amarot@ulb.ac.be>:

Le 10-juin-09 à 22:11, Michael Rueger a écrit :

...

we could move save as and save as version into a save as sub-menu. that would leave save save as quit

as choices.

I would prefer a menu like this :

-'Save' -'Save ...' -> 'Save as', 'Save as new version', 'Save and Quit' -'Quit'

Where the less used options are in a sub-menu.

I'll be glad to have the "Save and Quit" option back :-)

Antoine

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Jun 10, 2009, at 2:56 PM, Michael Rueger wrote:

Nicolas Cellier wrote:

...

What about auto-adaptative menus learning your habits.

X most used items on top. Y often used items following. Every other less used items in submenus.

you mean the most horrible idea MS ever had, changing menus?

-10^age of the universe ;-)

Hah! I agree wholeheartedly. Changing menus are not fun. I use Save and Quit all the time... this is starting to smell like a preference. If you want super short menus, then turn it off, if you want the convenience, then have it on... what say? - Brian

Michael

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

How to customize the menus? Customization == Preference, OK these are synonyms. Among the propositions so far: 1) override a method 2) some specific hard-wired Preferences 3) automatic some drawbacks: 1) require maintenance at each update 2) why a Preference for an item and not another ? 3) changing menus are painful (MS lacks some inertia for sure...) So far, I agree on 4) keep a simple static menu ...unless customization be accessible right from the menu (halos?) rather than from an obscure path. And easily undo-able (for example, items could be there but just undisplayed...) Nicolas 2009/6/11 Mariano Martinez Peck <marianopeck@gmail.com>:

what about having a preference to enable/disable "save and quite" from menu?

On Wed, Jun 10, 2009 at 6:30 PM, Brian Brown <brian@ablelinktech.com> wrote:

...

On Jun 10, 2009, at 2:56 PM, Michael Rueger wrote:

...

Nicolas Cellier wrote:

...

What about auto-adaptative menus learning your habits.

X most used items on top. Y often used items following. Every other less used items in submenus.

you mean the most horrible idea MS ever had, changing menus?

-10^age of the universe ;-)

Hah! I agree wholeheartedly. Changing menus are not fun.

I use Save and Quit all the time... this is starting to smell like a preference. If you want super short menus, then turn it off, if you want the convenience, then have it on...

what say?

- Brian

...

Michael

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

No preference. Preferences are for the weak :) We want to have design decision no absence of decision by preference plague. So guys come up with a good solution and we will use it but no preference. So I could not understand the proposals except this one: -'Save' -'Save ...' -> 'Save as', 'Save as new version', 'Save and Quit' -'Quit' So could you use this pattern to explain what you think/want? Stef

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

Hi, I like very much the idea of Save as to provide the new version name by default. But, I have there is a usability problem with "Save and quit" being spatially close to "Quit". The difference between is quite large, and you want to use them for very different scenarios: - I want to use "Quit" and not save when I perform experiment changes on objects that I do not want to keep with me (for example when I have some expensive computation and then want to play with some variation at the end). - You would want to use "Save and quit" typically when you work on code and want to keep it The problem is that because they are close, it will be easy to click on the other one by mistake (it happens all the time with long menu and small fonts). So, if you really want to reintroduce "Save and quit" it should at least not be close to "Quit". A minimal defense would be a separator between "Save and quit" and "Quit": "Save" "Save as..." "Save and quit" ----- "Quit" But, here is another idea. In VisualWorks we introduced a small add-on that prompts you to save the image after publishing in the repository, and when closing the image. Like this we instill the good practice of publishing and saving the code so that even if the image crashes, you are in sync with the repository. So, as a result you can always quit without saving. Would it not be better to prompt for saving the image after you save something in a Monticello repository? Cheers, Doru On 11 Jun 2009, at 09:46, Adrian Lienhard wrote:

OK, here again the proposal of Lukas that I think is the best so far.

--------- "Save" "Save as..." "Save and quit" "Quit" ---------

The behavior of "Save as..." would be modified to automatically pick the next version number (but still lets you edit the file name). Like this, "Save as next version" is not needed anymore.

Adrian

On Jun 11, 2009, at 09:25 , Stéphane Ducasse wrote:

...

No preference. Preferences are for the weak :) We want to have design decision no absence of decision by preference plague. So guys come up with a good solution and we will use it but no preference.

So I could not understand the proposals except this one:

-'Save' -'Save ...' -> 'Save as', 'Save as new version', 'Save and Quit' -'Quit'

So could you use this pattern to explain what you think/want?

Stef

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

I like this one too.I don't like "Save" ..> "Save", "Save as".. etc, to much cliks (or moves) just to save On Thu, Jun 11, 2009 at 9:17 AM, Alain Plantec <alain.plantec@free.fr>wrote:

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

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

So except if there is a huge pression or a cool argument we would like to keep save/quit and not have save/quit/save and quit

I am also in favor of adding "Save and quit". Get rid of "Save as new version" instead, I never use this one. Speaking of it, "Save as..." could be made a bit smarter and not suggest the same image name as default, but the next version. Lukas ;-) -- Lukas Renggli http://www.lukas-renggli.ch

Love the minimal menus in Pharo. Squeakish menus make me squeamish. Glad to not have Save and Quit Could lose Save as New Version. 2009/6/10 Nicolas Chillo <nchillo@gmail.com>:

On Wed, Jun 10, 2009 at 5:13 PM, Lukas Renggli <renggli@gmail.com> wrote:

...

...

So except if there is a huge pression or a cool argument we would like to keep save/quit and not have save/quit/save and quit

I am also in favor of adding "Save and quit".

Get rid of "Save as new version" instead, I never use this one.

Speaking of it, "Save as..." could be made a bit smarter and not suggest the same image name as default, but the next version.

And maybe, the posibility to save in a diferent path. ;-) Nico

...

Lukas ;-)

-- Lukas Renggli http://www.lukas-renggli.ch

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Lukas Renggli wrote:

...

So except if there is a huge pression or a cool argument we would like to keep save/quit and not have save/quit/save and quit

I am also in favor of adding "Save and quit".

Get rid of "Save as new version" instead, I never use this one.

I use it at least once a day. You learn that when working on core stuff, one innocently looking change and there goes your image ;-) Michael