GNOME Bugzilla – Bug 504876
Emoticon panel problem with Metacity Compositor
Last modified: 2008-01-03 23:54:54 UTC
Please describe the problem: Trying the new metacity compositor 2.21 [2] using Xrandr extension, I found a bug in combination with emesene. In particular the issue is the following. When I click the first time the emotiocon panel, it shows well. If I click twice, I get the panel not displayed but registered in metacity, because I noticed the presence in taskbar. If I click in the invisible area of the panel I get the emoticon. At last, If I close and reopen the window we start from the first good case. Here some screenshot[1] Could be that the panel the second time is under the main windows? In this case it will be related with other bug. PS this bug is also reported in emsene trac in [3] [1] http://farm3.static.flickr.com/2402/2126257641_48468bf15f_o.png [2] http://blogs.gnome.org/metacity/2007/12/19/2215-is-out-with-the-compositor/ [3] http://emesene.org/trac/ticket/249 Steps to reproduce: 1. Open a emesene windows. Click to insert a emoticon with metacity compositor enable. Insert it! 2. The click a second time and here's the bug. The panel is invisibile but is there. Actual results: Expected results: Does this happen every time? yes Other information:
Created attachment 101473 [details] (Testcase) Standalone script that displays that window. This is a reduced version of SmilieWindow.py, the module that displays that window, that i've adapted to be standalone and include a tiny version of our Theme class. There are more comments in the script itself It searches for smileys in ./images/, but should work well without them. I've included instructions on how to download them, if the problem is related to the heavy pixbuf usage. There are also some uncommon WM properties, and the bug seems to be after showing, hiding, and showing again. I don't have metacity compositor, so I can't test it. But it should be the same as launching emesene.
Created attachment 101701 [details] C program to demonstrate bug
It seems that when calling gtk_widget_hide on an undecorated window stops the compositor from drawing that window.
Ok, what was happening was when the undecorated window was being hidden, for some reason it was being removed from the compositor but it wasn't being added back to the compositor when it was shown again. This should be fixed in trunk of svn.
Perfect. Thank you very much. Well done!