GNOME Bugzilla – Bug 469085
Reimplement load/save and auto resume
Last modified: 2008-11-04 01:22:14 UTC
Please describe the problem: Gnome-sudoku is designed to automatically save the current game state when closing and restore any previous state when starting. This worked correctly in previous versions, but has stopped working recently (not sure exactly when). The game state is not saved, nor is it restored. Steps to reproduce: 1. gnome-sudoku 2. enter a number in an open square 3. File > Close 4. gnome-sudoku (restart) 5. the game state returns to the initial state--the change in step 2 is lost Actual results: The game state always returns to the initial state Expected results: The game state, including the user's changes, should be restored Does this happen every time? Yes Other information: Building and running the latest source package (gnome-sudoku-0.7.1) from http://sourceforge.net/project/showfiles.php?group_id=142841 from a temporary location, shows the correct behavior. The game is saved to a gconf string: $ gconftool-2 -R /apps/gnome-sudoku ... current_game = 8 0 1 0 0 4 0 0 0 0 0 0 0 6 0 0 5 0 3 0 2 7 0 0 0 0 6 0 9 0 0 4 0 0 0 7 2 0 0 3 0 9 0 0 5 1 0 0 0 5 0 0 2 0 6 0 0 0 0 7 4 0 2 0 7 0 0 8 0 0 0 0 0 0 0 6 0 0 3 0 9 Running the Fedora-packaged gnome-sudoku subsequently does not initialize the game to this state. If I remove all the items under /apps/gnome-sudoku, run g-s and re-check the items, this is what I get: $ gconftool-2 --recursive-unset /apps/gnome-sudoku $ gnome-sudoku $ gconftool-2 -R /apps/gnome-sudoku height = 675 show_tracker = false always_show_hints = 0 show_toolbar = 1 generate_puzzles_in_background = 1 width = 700 bg_black = 1 minimum_number_of_new_puzzles = 90 current_game = player = show_impossible_implications = 0 bg_custom_color = zoom_on_resize = 1 group_size = 9 difficulty = 0 font_zoom = 0 Note that the "current_game" item is empty. Running the sourceforge version sets a value for the "current_game" item as shown above. A diff of the gconf state (starting from empty) for the two versions: $ diff -u gs??? --- gs071 2007-08-21 22:01:42.000000000 -0400 +++ gs218 2007-08-21 22:00:55.000000000 -0400 @@ -1,11 +1,12 @@ + height = 675 + show_tracker = false always_show_hints = 0 show_toolbar = 1 - show_tracker = 0 generate_puzzles_in_background = 1 - minimum_font_size = 7168 + width = 700 bg_black = 1 minimum_number_of_new_puzzles = 90 - current_game = 4 0 1 9 0 3 0 0 6 9 7 8 0 4 6 0 0 5 0 0 3 8 5 0 0 1 0 6 0 2 5 0 0 0 0 0 0 1 0 0 0 0 0 9 0 0 0 0 0 0 8 1 0 7 0 8 0 0 6 2 3 0 0 3 0 0 7 1 0 4 5 8 7 0 0 3 0 5 6 0 1 + current_game = player = show_impossible_implications = 0 bg_custom_color = My Python environment (updated Fedora 7): $ rpm -qa | grep -i 'python' gnome-python2-canvas-2.18.1-1.fc7 gnome-python2-gtksourceview-2.18.0-1.fc7 gnome-python2-applet-2.18.0-1.fc7 gnome-python2-2.18.1-1.fc7 gnome-python2-gnomevfs-2.18.1-1.fc7 python-crypto-2.0.1-7.1.fc7 python-setuptools-0.6c6-1.fc7 audit-libs-python-1.5.3-1.fc7 cracklib-python-2.8.9-10 gnome-python2-gtkhtml2-2.14.3-4.fc7 python-urlgrabber-2.9.9-5.fc7 libselinux-python-2.0.14-4.fc7 notify-python-0.1.0-4.fc7 python-2.5-12.fc7 gstreamer-python-0.10.7-2.fc7 gnome-python2-libegg-2.14.3-4.fc7 python-libs-2.5-12.fc7 libxml2-python-2.6.29-1.fc7 gnome-python2-bonobo-2.18.1-1.fc7 gnome-python2-extras-2.14.3-4.fc7 rpm-python-4.4.2-46.fc7 dbus-python-0.81.1-1.fc7 python-devel-2.5-12.fc7 python-ldap-2.3-1.fc7 gnome-python2-desktop-2.18.0-1.fc7 gnome-python2-gnomeprint-2.18.0-1.fc7 python-imaging-1.1.6-3.fc7 gnome-python2-gconf-2.18.1-1.fc7 python-numeric-24.2-4.fc7
This is the intended behavior for gnome-sudoku. Many users were confused by the auto-resume feature and saving the game state was causing too much trouble. Expect this feature to be re-added in 2.22 as a preference (defaulting to off)
Ok, I can see that the automatic save/restore is not what most people are accustomed to, but to remove that, leaving no way to save a game, even manually, doesn't seem like a great plan either. Maybe I'm the colossally stupid exception, but I generally can't finish a puzzle in one session, so having no way to save a partially completed puzzle means the game (as it is now) is not usable for me. Why not revert the game to a straightforward save/restore menu, with the option to do it automatically? Most people would be familiar with that. Maybe that's already what you have in mind; I would vote for that too. Thanks for the response--I get the picture. Close it.
What you describe is exactly what will be in 2.22. The problem with the previous solution was that all games were saved to one file. This file tended to get corrupted leaving the game in a state where it would not start. Thomas Hinkle (the author of the game) has a new solution ready but we are in feature/ui/string freeze so that's why it'll have to wait for 2.22. I'm sorry that it is not usable for you in the current version but at least it will be next version. And thanks for bug report anyway. I can see you took the time to do some proper research. I'll leave it open for others to find if they search for it.
As Thomas said, the save and load features of GNOME Sudoku was removed because of all the problems people experienced with it. There was a whole lot of crashes reported through bugzilla to version 2.18.x. Part of the problem is that GNOME Sudoku is heavily threaded, causing memory corruption. After saving/loading was disabled, it seems that there are far less bugreports to GNOME Sudoku. If a new solution for saving and loading is to be implemented, commit it early in a development cycle, and make sure it works :-)
I already have a patch to add save/open functionality. It seems like adding an auto-backup would be easy as well. While I'm at it, I as might as well save users the pain of losing games. Here's my proposed solution (which may not require an option): 1. Add open/save options generally, moving to a file-based game system. 2. Automatically save games to a special location while playing ('.sudoku_latest_game'?). 3. When we start up, look for the latest game -- if it's there, offer the user the possibility of opening that game or starting a new one. The only potential problem is multiple games. Perhaps the user needs to choose whether to A) open the auto-saved game B) ignore the auto-saved game C) throw out the auto-saved game.
Patch is now attached to bug 484691. The patch has changed a bit with more input and thinking from what I described above. This patch will not restore the old behavior, which would have been confusing, nor will it add an extra preferences option (I'd like to avoid a preferences dialog if possible). Rather, this patch makes it so when you start into sudoku, you see a screen where you can select to resume your previous game or start a new one. Should be the best of both worlds.
I don't know if this is related, but created sudoku games and high scores are also not saved. Whenever I open Sudoku, the same game is opened, no matter how many times I solved it. The high scores are not updated either.
This is already fixed. Closing.