GNOME Bugzilla – Bug 757447
gnome-mines : Zero seconds high-score upon winning
Last modified: 2015-11-02 13:12:36 UTC
Created attachment 314594 [details] screen shoot showing zero second high scores Description of problem: I can consistently get high-scores of zero seconds. I updated from Fedora 21 to Fedora 23rc10 recently, I copied over my home directory from backup. When I went to try gnome-mines, I was able to finish a game in under a minute. However it reported my time as zero; old high-scores seem to be preserved. https://bugzilla.redhat.com/show_bug.cgi?id=1276944 How reproducible: Play and win a game. Steps to Reproduce: 1. Play game 2. Win Actual results: High-score of zero seconds added Expected results: Actual time to complete used Last entries of ~/.local/share/gnome-mines/history 2015-10-28T09:08:52-0700 16 16 40 64 2015-10-28T09:49:14-0700 16 16 40 71 2015-11-01T07:23:55-0800 16 16 40 0 2015-11-01T07:30:59-0800 16 16 40 0 2015-11-01T07:43:19-0800 16 16 40 0
I followed the instructions at https://wiki.gnome.org/Newcomers/BuildGnome . jhbuild sysdeps --install ; dnf install foo-devel bar-devel baz-devel kitchen-sink bathroom-tub toaster ; jhbuild build adwaita-icon-theme dconf glib-networking gvfs gnome-mines ; finally jhbuild run gnome-mines that one works just fine, the one packaged with fedora still broken. I have gnome-mines-3.18.1-1.fc23.src.rpm downloaded, Tomorrow, I'll break it open and compare it to the stuff in ~/jhbuild/checkout/gnome-mines/ . Specifically I'll diff the vala source files and see if anything stands out to me.
I feel this is a duplicate of bug 756302, as the behaviour is similar: the timer being reset at the end of the game would mean saving the high score as 0. As 3.18.1 was the last stable release, and the fix was committed after that one, I will make sure to have a release for 3.18.2 (due next Monday), maybe sooner, and that will hopefully get in the Fedora updates after the GNOME 3.18.2 release. Thanks for taking the time to report this. This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed in the code repository. *** This bug has been marked as a duplicate of bug 756302 ***
Sorry yes it does look like duplicate and shouldn't be very difficult to fix. I was able to do a `git diff 3.18.1 2facae8c64df52494ca0a1eb847d68e430f7f0ea` and the fix stood right out. diff --git a/src/minefield.vala b/src/minefield.vala index 5a7dfaf..f015983 100644 --- a/src/minefield.vala +++ b/src/minefield.vala @@ -101,9 +101,7 @@ public class Minefield : Object { get { - if (clock == null) - return 0.0; - return clock_elapsed + clock.elapsed (); + return clock_elapsed + (clock == null ? 0.0 : clock.elapsed ()); } } @@ -395,6 +390,7 @@ public class Minefield : Object { if (clock == null) return; + clock_elapsed += clock.elapsed (); if (clock_timeout != 0) Source.remove (clock_timeout); clock_timeout = 0; around line 245 of minefield.vala you detect the winning condition, which calls stop_clock() at around line 389 . stop_clock() sets clock to null . You return back and then cleared_cb() in gnome-mines.vala around line 719 is called. It uses elapsed getter at around line 100 of minefield.vala . And as we clearly see from the diff, if clock is null, it will always return 0.0 .
In the future, you can use https://git.gnome.org/browse/gnome-mines to get an easier view of the changes. (In reply to Robert Roth from comment #2) > I feel this is a duplicate of bug 756302, as the behaviour is similar: the > timer being reset at the end of the game would mean saving the high score as > 0. As 3.18.1 was the last stable release, and the fix was committed after > that one, I will make sure to have a release for 3.18.2 (due next Monday), > maybe sooner, and that will hopefully get in the Fedora updates after the > GNOME 3.18.2 release. Thanks for taking the time to report this. Normally we have a Fedora update created a day or two after your release. :) Please ping me if you notice it hasn't happened.