a plea for "save and quit"

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

which could also be from what I understand

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


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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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:

--
www.tudorgirba.com

"The coherence of a trip is given by the clearness of the goal."





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

you mean

quit
        should be always
        asking to save?


On Jun 11, 2009, at 12:21 PM, Michael Roberts wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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:


_______________________________________________
Pharo-project mailing list
[hidden email]
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<[hidden email]> wrote:
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

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.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

_______________________________________________
Pharo-project mailing list
[hidden email]
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 <[hidden email]>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

+1

I use save and quit more than any of the others, it was just the wrong
one to remove.

--
Ramon Leon
http://onsmalltalk.com

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I like this one too.
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project