Trapping the Pharo window close event

How do you get rid of that "Quit Pharo without saving message" that comes up when you try to close the Pharo window? I want to just let the user exit without any message or perhaps replace the message with one of my own.

Many thanks for that helpful and amazingly fast answer!

I did not really get it. Now I have the impression that changing the method definition shows that Pharo does not
offer the correct possibility.
Am I correct?

Stef

The closing is intercepted in

PasteUpMorph>>windowEvent:

from where this is called

WorldState>>quitSession

| save |

save := self confirm: 'Save changes before quitting?' translated orCancel: [ ^ self ].

save 

ifTrue: [Smalltalk snapshot: true andQuit: true] 

ifFalse: [Smalltalk snapshot: false andQuit: true]

So you can change the method for example to

WorldState>>quitSession

Smalltalk snapshot: true andQuit: true

(or snapshot: false if you don't want to save)

Or you can close it by clicking on world menu and selecting "Save and quit".

Peter

On Thu, Apr 14, 2016 at 7:57 PM, kmo <[hidden email]> wrote:

How do you get rid of that "Quit Pharo without saving message" that comes up
when you try to close the Pharo window? I want to just let the user exit
without any message or perhaps replace the message with one of my own.





--
View this message in context: http://forum.world.st/Trapping-the-Pharo-window-close-event-tp4890079.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

As a developer you need to be able to control the program shut down. That is a given.

I think I was expecting something like the Dolphin approach but it doesn't exist in pharo. Having to overwrite an existing method is not elegant but it works.

A similar issue exists with Growl notifications - I have a post on this as well.

The Dolphin approach was described by Estaban earlier in this thread. I've never used Dolphin myself so cannot expand on it.

Pharo is yours, so you can add it. :)

Yes, but I don't want to add it. I expect it to be there out of the box. I think it's quite enough work for me to add my own code on window close. I don't want to have to write the framework for doing it as well.

Well, my reply was rather tongue-in-cheek. I was mocking my own laziness and the laziness of developers like me. But really I have no problem in doing these things for myself. And I hope that soon I will be in a position to contribute to pharo myself.

But overriding the close event is something any application developer is going to want to do. And every time you make a developer work harder than necessary to implement a basic feature you make the pharo platform less attractive. If you want more developers to use pharo you have to make basic things like this easy to do and easy to find out how to do.

I do think that deployment of applications gets very little attention in pharo - yet it's a major issue of you want to make pharo a widely-used application platform.

I'm not the only lazy developer, you know .

My point is that it is a proof that a library is not good when it forces users to redefined core code.

Stef

I did not really get it. Now I have the impression that changing the method definition shows that Pharo does not
offer the correct possibility.
Am I correct?

I disagree. Closing the window should not decide on it's own whether the session should be saved. Asking the user is the right thing.

The ideal thing would be to not ask if nothing has happened... but that's impossible, this is a live system, not a text editor.

Peter

Le 16/4/16 11:33, kmo a écrit :
> /Pharo is yours, so you can add it. :)/
>
> Yes, but I don't want to add it. I expect it to be there out of the box.

So you believe either is modern slavery or magic auto generation :D
Seriously if you that need it are not ready to invest 30 min why me that
does not need it should do it?
Do you know what is free open-source software?

Le 16/4/16 12:18, kmo a écrit :
> Well, my reply was rather tongue-in-cheek. I was mocking my own laziness and
> the laziness of developers like me. But really I have no problem in doing
> these things for myself. And I hope that soon I will be in a position to
> contribute to pharo myself.

But you are :)
30 min a week is enough :)
>
> But overriding the close event is something any application developer is
> going to want to do. And every time you make a developer work harder than
> necessary to implement a basic feature you make the pharo platform less
> attractive. If you want more developers to use pharo you have to make basic
> things like this easy to do and easy to find out how to do.
We know that.
Now I will not give the HUGE list of the things we are working on and
that default
developers are in need:
     - good file library
     - good list widget
     - FFI
     - decent texteditor
     - a compiler :)
     - ...

>
> I do think that deployment of applications gets very little attention in
> pharo - yet it's a major issue of you want to make pharo a widely-used
> application platform.
Indeed. We started to push that when damien worked on the launcher and
we should continue.