1. Anders Ruud
  2. love

Issues

Issue #24 resolved

love.quit

Luiji Maryo
created an issue

How about a callback called love.quit that is called after the "q" event? I don't know of a way to handle such an event without creating my own love.run at the moment, and I'd prefer to use the default love.run so that when LOVE upgrades I get the latest and best love.run loop.

It appears that overwriting love.handlers would not work, since the "q" event quits before love.handlers can be called.

I need this functionallity for a game engine I'm working on to automatically save the game settings on close.

{{{ -- Example of how it would work on the game developer's side. function love.quit() -- Due some stuff. print "BOO! Quitter." end }}}

{{{ -- Example of how love.run would look: -- ... love.run code ... if e == "q" then if love.audio then love.audio.stop() end -- <<< Added Code >>> love.quit() -- <<< End of Added Code >>> return end -- ... rest of love.run code ... }}}

Also, why I'm here, any idea when the next release will be out?

On that note of off-topicing, what's the difference between an enhancement and a proposal?

Comments (13)

  1. Andrzej Giniewicz

    I think it would be nice if love.quit could cancel the quit if love.quit returned false or nil, i.e. to get stuff like:

    someone presses "x" on window to close it, then game actually changes state to ask if someone wants to leave loosing progress, if someone press "yes" we close, if "no" we continue - while implementation of that stuff would be done by user, simple ability to return true/false from love.quit to confirm/cancel quit event would be enough - i.e. love.quit can be coded to always return false unless "yes" or "don't ask me again" was clicked in confirm window... stuff like that, of course default love.quit can always return true :) What do you think?

  2. Robin Wellner

    Andrzej Giniewicz: if so, it would make more sense to make true abort quitting. This because the most simple use of love.quit would be to do some cleanup/autosave before LÖVE closes. It makes more sense to let love.quit return nil/a false value if it doesn't want to stop the closing process.

  3. Andrzej Giniewicz

    well, yeah - that's what I said - false for cancel (cancel quit operation), true for confirm (confirm quit and really quit). So someone can make it return false (not quit) unless "yes" or "don't ask me again" was clicked in confirm window (when it returns true and quits).

    Probably didn't made it clear enough - but anyway, it is a detail how it is done, it's important that it will be possible to do lots of different things then, esp it's only way to cancel closing window trough "x". Currently quit event is as I understand it always generated when close request from WM is processed, and thus eventually loop is always stopped, right?

  4. Andrzej Giniewicz

    Oh, one thing - I think if it will be added, nil should quit the application so probably false should too and anything else should cancel quitting, so other way around than I described it - because if love.quit() does not return anything, then it's value is nil and it would make sense to quit then. Then stuff like

    if love.quit and not love.quit() then (stop the loop) end
    

    might work.

    I don't know, that's just thing that came to mind.

  5. Luiji Maryo reporter

    So

    if love.quit then
      if love.quit() then return
    else return
    end
    

    would be what we want, yes?

    If so, then I'm going to post an example of this to the Wiki in the tutorials (and I'm going to make it more of a tutorial unlike my last attempt with rectangular collisions). I.e., I'm actually going to explain it.

    Thanks for liking this idea!

  6. Luiji Maryo reporter

    Right now it seems we are attempting to create a resolution for 0.6.x users until 0.7.x comes out (which I here will be quite awhile), this way we can create a Tutorial for people who need the functionality right here right now (like I do).

  7. Log in to comment