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 396243 - Character detail window closes too fast to read (simple solution, I think)
Character detail window closes too fast to read (simple solution, I think)
Status: RESOLVED FIXED
Product: gucharmap
Classification: Core
Component: general
1.8.x
Other All
: Normal normal
: ---
Assigned To: gucharmap maintainers
gucharmap maintainers
: 312694 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-01-13 21:27 UTC by Rafał Mużyło
Modified: 2007-12-12 19:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Rafał Mużyło 2007-01-13 21:27:33 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:
Comment 1 Rafał Mużyło 2007-03-09 18:40:17 UTC
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.
Comment 2 Rafał Mużyło 2007-03-09 19:07:06 UTC
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.
Comment 3 Noah Levitt 2007-03-10 03:10:49 UTC
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.)
Comment 4 Rafał Mużyło 2007-03-10 16:49:53 UTC
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.
Comment 5 Elliott Sales de Andrade 2007-07-17 07:28:34 UTC
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.
Comment 6 Andrew Kemp 2007-07-22 09:35:37 UTC
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.
Comment 7 Rafał Mużyło 2007-07-22 21:06:30 UTC
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.
Comment 8 Christian Persch 2007-12-09 14:29:54 UTC
*** Bug 312694 has been marked as a duplicate of this bug. ***
Comment 9 Christian Persch 2007-12-09 14:30:38 UTC
Making the window GTK_WINDOW_POPUP is the right fix here.
Comment 10 Christian Persch 2007-12-12 19:26:23 UTC
Fixed in svn trunk.