GNOME Bugzilla – Bug 396243
Character detail window closes too fast to read (simple solution, I think)
Last modified: 2007-12-12 19:26:23 UTC
Please describe the problem: The character detail window - one called by either right mouse button or a Shift key - closes immediately after it gets opened. There's no chance of reading its contents. First, a few details. 1. I'm not running gnome. 2. My window manager is Openbox, set with "focus follows mouse" 3. I'm using 1.8.0, but the catch is I tried 1.6.0 and 1.4.4 and the bug is there too. The funny thing is that I know it worked in the past, and although I don't remember the version number, I think it was post-1.4.4. Actually, I suspect that the reason was some fairly recent change in glib/gtk. Curently using glib-2.12.6 and gtk+-2.10.6. I tried going through source, well actually I was trying to make it compile with GTK_DISABLE_DEPRECATED and stuff, did that too, although effect was unsatisfying - gtk_combo_box is simply butt-ugly with such long lists...but coming to the point, I almost fixed it, at least I found where does the problem come from. It's in gucharmap/gucharmap-table.c. If I put a comment on line gucharmap_table_zoom_disable (chartable); in static gboolean focus_out_event(GtkWidget *widget,GdkEventFocus *event,GucharmapTable *chartable) right mouse button seems to work correctly most of the time, however in that case shift key sometimes needs to be pressed two times to activate detail window, and mouse button sometimes fails too, but if I press and hold the mouse button while it fails,and move mouse to a different character, detail window appears as it should. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
First, I'd like to complain, that this bug is is unconfirmed, regardless of the fact, that debian bugzilla has similar bug (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=368134). Now, I'd like to say that I think I found a very simple solution, that seems to be correct. If zoom_window is created as GTK_WINDOW_POPUP instead of GTK_WINDOW_TOPLEVEL, everything seems to work fine without commenting that line out. BTW, problem exist still in 1.9.0 and this solution still works.
And for consistency in po/pl.po line msgstr "Wdług pi_sma" should probably be msgstr "Według pi_sma" as msgid "By _Unicode Block" is. Also in msgstr "_Znajdź:" for msgid "_Search" that colon at the end looks a bit strange for a menu. As an idea: for actions "Find", "Quit", and "About" consider using NULL instead of current strings, as other then loosing three dots at the end of "Find" I can see no bad points of using their standard translations from gtk.
galtgendo, the window stays there as long as you hold down the mouse button or shift key. It was intended to work that way and it has always worked that way. (If you want to question that design decision, fair enough, but that doesn't seem to be what you're saying.)
Well, the problem is it SHOULD stay, but it does NOT. It disappers almost instantly after being shown. I press and hold, it blinks in and then it's gone. But if it's changed to GTK_WINDOW_POPUP, it behaves as I believe it should (and your comment seems to confirm it). I point you back to the bug report, maybe it's because I have "focus follows mouse" I can see this issue.
I can confirm that the same behaviour is observed when using some other window managers, namely beryl or compiz. This is with the new 1.10.0. The problem does not appear when using metacity. In addition, changing zoom_window from GTK_WINDOW_TOPLEVEL to GTK_WINDOW_POPUP does fix the problem. An added bonus is that the zoom window does not show up in the window list (which I found slightly annoying). I think this style corresponds with the actual use of the window as well. I'm not sure how twm works with regards to popup windows, but this may also fix the problem in bug #312694.
I also see the incorrect behaviour with the Sawfish window manager and Gucharmap 1.10.0, but only if it is configured to give the input focus to application windows when they first appear. If this option is turned off then the detail window does indeed stay open for as long as the mouse button or shift key is pressed.
Well, while this bug was being ignored here, I sent a bug report to openbox mailing list. You can read the whole answer at http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?24:msn:4921:jbbegcmagmgilbkgmbop As this affects other window managers too, it seems that the bug is caused by relying on a metacity specific behavior.
*** Bug 312694 has been marked as a duplicate of this bug. ***
Making the window GTK_WINDOW_POPUP is the right fix here.
Fixed in svn trunk.