GNOME Bugzilla – Bug 335243
Child window sometimes misaligned
Last modified: 2006-06-30 15:12:39 UTC
Please describe the problem: I'm using sawfish, and the dropdown window initially appears at the top left of the screen. If you continue to type it moves to the proper location. Steps to reproduce: 1. Start typing in the text entry field. 2. Alternately, have it configured as a button in the panel, and press the button. Actual results: Drop down window appears in top left of screen Expected results: Drop down window to appear positioned under the applet Does this happen every time? Yes Other information: I have some screenshots of this, will attach. Using version 2.14.0.1-0ubuntu2.
Created attachment 61633 [details] Initial state of dropdown after typing some characters
Created attachment 61634 [details] State after pressing button in panel mode
I don't know what's going on precisely, will need investigatio..
I'm using center as Sawfish windows placement mode, so the deskbar input window appears in the center of the screen. As a workaround, i've added a rule in "Matched Windows" for panel windows with "place-mode=none".
In metacity, if you set /app/metacity/disable_workarounds to TRUE then this same thing happens. In addition, it only happens when you click the applet, not when you use the key-combination. Other applets (e.g., CPU Frequency Scaling Monitor, Volume Control, Window Selector) react correctly with disable_workarounds as TRUE, so this is a Deskbar bug.
Can you guys still reproduce this? A lot of changes has landed in the tree...
I just got the latest CVS version and tried it in window mode. It still is broken without any symptom changes.
OK, just to let you know that I'm actually working on this. It has proven to be quite tricky... Eric: Is it also still bugged in entry-mode? I have it working here with disable_workarounds=True. Regarding button mode; here's the problem. Right now the popup window is actually a gtk.WINDOW_TOPLEVEL and windowmanagers do various stuff to those (hence the misplacement). The right solution is to use a gtk.WINDOW_POPUP (I will refer to such as just popups) which is ignored by the WM. This has a bunch of sideeffects though which I'm trying to tackle right now. The root of the troubles is that a popup cannot have the input focus since the wm ignores it, thus we have to relay events somehow. This is trickyfied by the fact the toplevel window containing the applet is the panel (a gtk.Plug).
Yes, it is aligned correctly. The problem now is that +/- do not work on the result tree. Have you tried changing the GdkWindowTypeHint of a gtk.WINDOW_TOPLEVEL window? It seems like this might be more of what you need. I am slightly confused by what does what because I see both POPUP and NORMAL (which is described as TOPLEVEL) in gtk and gdk, so I cannot tell if the gtk window type matters if you are changing the gdk hint. http://developer.gnome.org/doc/API/2.0/gdk/gdk-Windows.html#GdkWindowTypeHint I did find detailed information about each of the hints is at: http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2507144 So from what I can tell, it should have the GDK_WINDOW_TYPE_HINT_DROPDOWN_MENU or GDK_WINDOW_TYPE_HINT_MENU hint.
Ok, I've commited something that fixes it for me atleast :-) (also the +/- thing) It required using a gtk.WINDOW_TOPLEVEL abd setting the gtk.gdk.WINDOW_TYPE_HINT_MENU. This had some other side effects, but I think I nailed most of them... Please update your cvs...
I works for me as well! Thanks a lot!