GNOME Bugzilla – Bug 727191
Custom size not working
Last modified: 2014-04-14 22:08:36 UTC
Tried gnome-mines from git master 07fc2194d3ef6cf239b0669674af5f646769c22c (march 24 2014). When I try to set a custom size, I can change the numbers, but when I click "play game", the resulting game is always the standard "medium" size (16*16 squares, 40 mines).
Hm, this one might be hard to track down: it's working perfectly for me :/
(In reply to comment #1) > Hm, this one might be hard to track down: it's working perfectly for me :/ D'oh! Will do some more testing next week when I have more time, to see if I can pinpoint the cause. Some more system details: Compiled gnome-mines in a Debian Sid chroot. Could you please tell me if you can reproduce Bug 727192 or not? If not, it is these two problems are related and the cause is something in my build environment.
Hm, I cannot reproduce that one either. A good sign the same root cause may be to blame.
Have tested some more in some different Debian systems. The problem can't be reproduced in a real (i.e not chrooted) Debian system. Both i386 and amd64 works fine then. The problem only occurs in a chroot (tested in Debian Sid). The terminal output is repeated some times: (gnome-mines:3247): dconf-CRITICAL **: unable to create directory '/run/user/0/dconf': Permission denied. dconf will not work properly. (gnome-mines:3247): dconf-WARNING **: failed to commit changes to dconf: The connection is closed Tried getting past this by creating requested directories with rw permissions and changing XDG_RUNTIME_DIR to use the uid of the user running gnome-mines. This however just changed the output: ** (gnome-mines:3784): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. (gnome-mines:3784): dconf-WARNING **: failed to commit changes to dconf: The connection is closed I'm closing bug 727192 as a duplicate as it seems extremely likely that the cause of that is the same, whatever the real cause is.
*** Bug 727192 has been marked as a duplicate of this bug. ***
Are other GNOME programs in the chroot able to use dconf, or is this really specific to Mines?
if dconf weren't installed or not working or anything, no matter in what way, a custom game should still work. I haven't looked at the code yet but maybe we should only try to load the settings once and don't reload them for new games, that way current settings would live until termination of the application. That could be a problem in other games as well, depending on the specific implementation of the passing of the parameters to the actual game-widgets.
So, it looks like mines tries to load settings from GtkSettings every time you start a custom game. Were saving to fail, for whatever reason, you wouldn't be able to customize your game. The least invasive fix would be to have an internal copy of those settings we could refer to, instead of loading them every time. We could also check whether GSettings is writable and if not, disable custom game mode. We just have to decide if not having writable settings is a case that we are supposed to support and in what cases this would be an issue.
(In reply to comment #8) > The least invasive fix would be to have an internal copy of those settings we > could refer to, instead of loading them every time. This seems like the way to go. In general, if gsettings is broken then it's reasonable for preferences dialogs to break, but I think custom game sizes should be more robust than that. Still, low priority since very few people will be using Mines with broken gsettings.
(In reply to comment #6) > Are other GNOME programs in the chroot able to use dconf, or is this really > specific to Mines? Here are some more results. While many gnome applications (some other gnome games, baobab, gedit tested) get the dconf-CRITICAL terminal messages, only gnome-mines showed any change in behaviour as far as my limited testing showed. As for the underlying cause, it looks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731300 which is libpam / systemd messing with the XDG_RUNTIME_DIR environment variable when using su, so probably not a Gnome bug.
"only gnome-mines showed any change in behaviour" yeah, one would guess the applications do not constantly query dconf for settings they already know. You are right, non-working dbus is not a bug for us to fix. Since supporting the use case would be quite easy, I guess we'll do a workaround in the near future anyway. I think we would want to hit 3.14, at least. This bug is now tagged with gnome-love. With this dissection of the bug, it should be easily fixable for any newcomer. Thank you Anders for reporting :)
Created attachment 274105 [details] [review] Store the dconf values instead of querying them
(In reply to comment #12) > Created an attachment (id=274105) [details] [review] > Store the dconf values instead of querying them Have tested this now, and this patch fixes both of the gnome-mines problems (custom size not working, mine percentage calculated incorrectly) that I experienced in my chroot.
Review of attachment 274105 [details] [review]: Seems good, thanks! It might be easier to try using g_settings_delay() and g_settings_apply() -- I haven't tried, but I suspect that would avoid this bug without having to add all the extra member variables. If not, then this approach is fine. ::: src/gnome-mines.vala @@ +415,3 @@ + settings.set_boolean (KEY_USE_QUESTION_MARKS, use_question_marks); + settings.set_boolean (KEY_USE_OVERMINE_WARNING, use_overmine_warning); + settings.set_int (KEY_NMINES, n_mines); Minor issue: can you please make sure these preferences get saved if and only if they have changed? It's a bug to write back the default value as that breaks our ability to update the default for users who upgrade to a newer version.
Created attachment 274263 [details] [review] Use "delay-apply" mode for GSettings This seems much simpler, thanks for the hint! :)
Anders, can you check if the new patch also fixes the bug? Thanks.
(In reply to comment #16) > Anders, can you check if the new patch also fixes the bug? Thanks. Yes, works fine. I'm impressed that you found a two line fix! :-)
Awesome, thanks everyone. Attachment 274263 [details] pushed as 5fc23fd - Use "delay-apply" mode for GSettings