After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 731529 - Settings start out with wrong opponent value
Settings start out with wrong opponent value
Status: RESOLVED FIXED
Product: four-in-a-row
Classification: Applications
Component: general
git master
Other Linux
: Normal major
: ---
Assigned To: four-in-a-row-maint
four-in-a-row-maint
Depends on:
Blocks:
 
 
Reported: 2014-06-11 15:14 UTC by Mario Wenzel
Modified: 2014-06-16 23:25 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Bug fix (1.72 KB, patch)
2014-06-14 09:46 UTC, Nikhar 		committed Details | Review

Description Mario Wenzel 2014-06-11 15:14:15 UTC 
It seems like, since e91514fa05020bd4e5520800e654864d5e2b02bb, Improve the window title of the preferences dialog, the settings dialog starts out with the human opponent always and doesn't load the correct value, even though the settings are correct.

The Dialog starts out as human opponent, even though an ai is playing against me.
Comment 1 Mario Wenzel 2014-06-12 13:46:25 UTC 
Sorry, seems like I mis-disected the issue.

That the settings dialog starts out as the wrong value was introduced in
ada921814fe960f2381550e2cbd0cd723e3d5bb0
"Fix regression in default opponent"

So even though we play against an ai, the settings show "human".
Comment 2 Mario Wenzel 2014-06-12 13:54:43 UTC 
And the issue is exacerbated with 30a035ca11383141ad4b093e0fb715cb06d22e58
Use a header bar on the preferences dialog

Where after we change the value and reopen the settings dialog, it has the wrong value again.

Before that, after changing the value it would stay consistent during the session.
Comment 3 Nikhar 2014-06-14 09:46:15 UTC 
Created attachment 278438 [details] [review]
Bug fix

I think that this bug has existed for quite some time now, much older than the commits mentioned.

Anyways, this patch should hopefully fix it.
Comment 4 Mario Wenzel 2014-06-14 09:59:23 UTC 
Review of attachment 278438 [details] [review]:

This wasn't invasive at all. Good work :)

I might think about backporting that to 3.12
Comment 5 Michael Catanzaro 2014-06-16 23:25:52 UTC 
Thanks for fixing this, Nikhar.  I'm going to do an unscheduled 3.12.3 release with this fix.