GNOME Bugzilla – Bug 148526
on win32, gdk_window_get_position and gdk_window_get_origin don't match
Last modified: 2004-12-22 21:47:04 UTC
Senario A: Move your start bar to the top of the screen. The y coordinate of get_position is N pixels greater than get_origin, where N is the width of the start bar. Senario B: With multiple monitors, if the primary monitor is not in the top left of the virtual desktop. get_origin reports units relative to the virtual desktop, get_position reports relative to the primary monitor. The most noticable effect of this bug (at least for me) is that drag and drop doesn't work. The x,y from gdk_window_get_geometry match gdk_window_get_origin. The coordinates reported by the configure-event, button-press-event, etc. also appear to match gdk_window_get_origin. It would seem that gdk_window_get_position should be modified to match the other the other functions, although I'm not sure what else this might break.
Would be useful to reopen the recent bug filed on this subject that was resolved NOTGNOME (about saving GAIM window positions) and dup it on this.
That would be bug #147693. It would appear that the coordinates provided by gtk_window_get_position are accurate, and when passed back to gtk_window_move the window stays in the same place on the same monitor. GAIM's problem is either that they are using different (and probably the wrong) functions to get/set the position, or a problem that has since been fixed.
*** Bug 148528 has been marked as a duplicate of this bug. ***
*** Bug 148590 has been marked as a duplicate of this bug. ***
*** Bug 147693 has been marked as a duplicate of this bug. ***
The reason gdk_window_get_position returns the wrong coordinates is that it uses the saved x and y coordinates in the window object, but in two places in gdkevents-win32.c where those are set a conversion is done to screen coordinates using ClientToScreen without adding the _gdk_offset_x and y values that is the difference between win32 screen coordinates and gdk coordinates (look in gdk/win32/gdkprivate-win32.h for a description of those variables). I have made a patch for gdkevents-win32.c that makes drag and drop work for me with correct coordinates in the testdnd program, when I have the taskbar at the top of the screen. It should be noted that there is another bug regarding _gdk_offset_{x,y} with windows of style GDK_WINDOW_TEMP that can be observed in The GIMP, but that is separate from this and I will file another bug report for that.
Created attachment 29977 [details] [review] Possible patch for gdkevents-win32.c The patch is against gtk-2-4 from anoncvs. Tested on Windows XP.
In case anyone wonders why I changed the test for top level windows in my patch, see discussion at the end of bug #137192. It also didn't seem to make sense to sometimes send different coordinates in the configure event compared to what is stored in the window object.
This patch works for me (with gtk+-2.4.1), and I've tested it against both of the initial scenarios. Thanks.
Tor, Hans, what do you think of this? Does my proposed patch seem to make sense?
Yes, makes sense. Will apply.
Patch applied to HEAD and gtk-2-4. Resolving as fixed.
*** Bug 151451 has been marked as a duplicate of this bug. ***