GNOME Bugzilla – Bug 543315
Refresh rate value is not saved when changed by key
Last modified: 2011-11-11 10:03:55 UTC
Please describe the problem: (See original submission at: https://bugs.launchpad.net/ubuntu/+source/gnome-system-monitor/+bug/154839 ) When changing the refresh rate in the settings dialog of gnome-system-monitor, the new value is not saved if the dialog is closed right after a change of value via the keyboard. "On the other hand if I change it via mouse (up/down arrows) the change is remembered." Steps to reproduce: 1. Open the setting dialog 2. Click once in the refresh interval edit box (to select the field making it editable) 3. Enter any number different than the current 4. Click Close immediately, without clicking anywhere else 5. Open the settings dialog again and verify that the value did not change Actual results: The value appears to be changed, but by opening the preferences dialog again, you can verify that the setting has reverted to the previous value. Expected results: The setting to be changed to the new value. Does this happen every time? Yes Other information:
Use your mouse. Serioulsy i don't know how to solve this: i'm not going to update the whole thing behind on every .1s increment. The current code applies the new value on focus_out_event.
Well, that was certainly a nice response: "Use your mouse." If you for some reason are not capable or willing to fix this bug, then may I suggest that you simply remove keyboard functionality altogether? It seems more sensible to limit the changes to be done by the mouse (which seems to work), than also allowing keyboard input which might - or might not - work. I'm not sure what you mean by ".1s increment". I'd assume most people simply enter the new value which might be several seconds different from the current - which only should trigger a single change of the value in the application. But if I understand you correctly, this bug is actually a "core" bug because "focus_out_event" is not triggered for the active control when closing a dialog? Or?
One solution would raise the eternal GNOME problem: instant apply or not ... the only way to fix this is to apply when leaving the configurator. but as soon as i'll do it, i would get bugs about settings only being applied when closing the dialog.
I'm not sure that I agree with you with this only being fixable by ONLY applying settings when closing the dialog. I'm not entirely sure of how everything is done in GNOME, but I can think of several logical solutions: 1) Apply the setting whenever the value is changed instead of when focus to a control is lost 2) If the "focus lost" event is supposed to be sent for the active control whenever a dialog is closed (which would seem logical?) - then fix that bug. 3) When the dialog is closed, check if the setting has been changed, and apply the new value if so. But then again, I'm not sure exactly how things are done in GNOME and GSM.
The problem is: "focus_out_event" is working, but new value is discarded when he closes the window. Steps to reproduce: - Use mouse to change value to "10.00", close and come back. - Using keyboard, type in a number, say, "5", and TAB out of the control (without hitting ENTER) - The number is correctly formated to "5.00", indicating that a "focus_out_event" was triggered - Close window and open it up again - Value will be 10.00 , indicating that both focus_out_event and closing window event did NOT save the value. Requiring the user to press ENTER in the textbox to save the value is, IMHO, completely non-intuitive and totally unacceptable as a solution. We are not asking for values to be constantly saved each time a user type in a key. We just ask it to be saved at all, be it on on focus_out (preferably) or window close.
Created attachment 198534 [details] [review] Makes changes to spin buttons by keyboard apply on window close or focus loss please note: apply this patch from in source Seems like gtk doesn't commit value changes before hitting ENTER or calling gtk_spin_button_update(). The updater will call gtk_spin_button_update() before evaluating the value.
Review of attachment 198534 [details] [review]: Looks fine, simple, tested it, and it does work.
Thanks. Fixed in commit abc1f5b47efa2dcd5f0e9c378283e9d9e6ac9fdf To make applying patches easier, please submit a git-formatted patch next time please.
*** Bug 611738 has been marked as a duplicate of this bug. ***