GNOME Bugzilla – Bug 159334
Changes not taking effect until after user hits return
Last modified: 2004-12-22 21:47:04 UTC
Description Cinnabar Solaris Sparc Build_15 on s10_63 with dual monitor -Launch gnopernicus magnifier -Open the preferences window -In the preferences window, click on 'Add/Modify' to open 'Zoomer Options' -Change some of the values in this window. -None of the changes take effect until after the user hits return. Changing values should take effect immediately Evaluation This is NOTABUG. While much of the Magnification GUI responds immediately, it is intentional that re-sizing the magnified view happen only when the user has finished entering a number and presses tab or <CR> or otherwise indicates they are done. Otherwise replacing "500" with "1024" would first result in replacing "500" with "1", the "10", then "102" - each time the magnified rectangle changing. Changing dynamically the end from "500" to "1024" this way (when it starts at "1") would mean that the user would temporarily have only a 1 pixel sliver magnified, then a 10 pixel sliver, etc., which would be far worse. peter.korn@sun.com 2004-08-09 This IS a bug, because 'TAB' and 'mouse click' are not working for the "source" and "target" entry fields. bill.haneman@sun.com 2004-11-11 13:55:44 GMT Comments There are conflicting understandings of what the tester is describing in engineering. Frances, can you please clarify: Which specific values are you changing in this window that aren't taking effect immediately (zoom factor? smoothing? focus tracking? zoomer placement?) Is "when the user hits return" effectign to close the dialog box, or is it simply finishing an edit of one of the four Zoomer Placement spin buttons? peter.korn@sun.com 2004-08-10 frances.keenan@sun.com 2004-08-11 --------------------------------- The value changes that aren't taking effect immediately are : -Display Screen : source and target -Zoomer Placement When the user makes a change to e.g. the zoomer placement - and hits return, the magnifier placement chanage to this new value. It does not close the dialog. You must hit enter after changing each value for it to take effect. Zoom Factor, Smoothing, and Mouse Tracking Mode changes occur immediately, no need to hit return. peter.korn@sun.com 2004-08-11 ----------------------------- Frances - thanks for the update; that mostly clarifies things. One last question: what happens when you TAB away from either -Display Screen : source and target or -Zoomer Placement fields after updating them? Also what happens when you simply click into another field with your mouse (basically move focus out of one of those fields)? Does the magnifier update in those cases? peter.korn@sun.com 2004-08-11 frances.keenan@sun.com 2004-08-11 --------------------------------- When you TAB away, the new value you entered in the field takes effect. Clicking into another field has the same action as TAB'ing away. Yes, the maginifer gets updated in both cases peter.korn@sun.com 2004-08-11 ----------------------------- Then I stand by the decision to close this as NOTABUG. As per separate e-mail from Calum, this behavior does comply with the GNOME HIG. peter.korn@sun.com 2004-08-11 With a nightly Cinnabar Solaris Sparc build installed from 2nd Nov 2004 The user must click return after changing the Source and Target values for them to take effect. Tabbing away does not update these values. Reopening this bug. frances.keenan@sun.com 2004-11-09 13:36:21 GMT Bugster Bug #5083128
From reading all the coments in this bug I was under the impression that this is NOT a bug, that changing the magnifier source/target on RETURN is the desired behaviour.
Created attachment 34544 [details] [review] proposed patch This patch also fixes bugs #159335 and #153622. "OK" and "Apply" buttons are added to the "Magnifier Options" dialog. The source and target will change whenever one of these buttons is pressed. Also some of the code from the patch from bug #153622 was added to check if the source and target screens are valid. The "activate" event from the source and target GTK_ENTRYs was removed.
Created attachment 34632 [details] [review] review patch Reworket patch
Created attachment 34792 [details] [review] patch removed "//" coment from patch
Dragan: I see that you don't gdk_display_close(), indicating bug 85715. But this leaves an X connection open every time you check the display - not good. It's not obvious that you need to wait for a fix to 85715. If you feel you must, then at least you should do something to prevent multiple gdk_display_open calls on the same display...
I agree that an X connection should not remain open, but if I try and close it gnopernicus segfaults. Shouldn't the displays be tested every time they are changed? I'm pointing to bug #85715 because all the web research I did to see why this function doesn't work sent me to this bug. I didn't find another way to test the display for validity.
yes, under the circumstances perhaps this is the best we can do. However I don't think we need to test the _same_ display more than once. perhaps the leak issue is not sufficiently important to justify storing a list of 'know good displays', etc.
Dragan: I tried the patch. If I set the 'target' display to an invalid value and then press 'OK', it seems to kill the window manager (on JDS Linux).
On my JDS Linux build 24b when I try to change to an invalid display it just beeps and reverts to the old value like it should. Source and target behave the same. Does this happen on 'Apply'? Do you have 2 frame buffers configured?
If the display is not valid you should here a beep, then the old value is entered in the entry. Do you here this beep?
problem is with 'ok', in which case there's no beep (on my system), but metacity crashes. I don't have a second DISPLAY configured.
This is wierd, 'Ok' does that same thing as 'apply' plus closing the dialog. It is true that when I try target ":8.9" it takes more time to check the display but I always get the same result.
Patch tested on 3 JDS systems including Linux and Solaris. No crash was seen on any of the systems. Patch applied to CVS HEAD and gnome-2-8 breanch. Closing bug...