Hi,
I read the following remark in gdkevents-win32.c:
/* If we haven't moved, don't create any GDK event. Windows
* sends WM_MOUSEMOVE messages after a new window is shows under
* the mouse, even if the mouse hasn't moved. This disturbs gtk.
*/
if (msg->pt.x + _gdk_offset_x == current_root_x &&
msg->pt.y + _gdk_offset_y == current_root_y)
break;
Can someone explain the meaning of "This disturb gtk" - this break in the code causes the following behavior in the application:
if the mouse is over a highlighted widget and the user executes Alt+Tab that shifts to another window on top of the highlighted widget - then, when shifting back with Alt+tab
brings the application into focus without the highlight.
if this a performance hack or does it really prevents a bug in GTK behavior?
Thanks,
Oved
I read the following remark in gdkevents-win32.c:
/* If we haven't moved, don't create any GDK event. Windows
* sends WM_MOUSEMOVE messages after a new window is shows under
* the mouse, even if the mouse hasn't moved. This disturbs gtk.
*/
if (msg->pt.x + _gdk_offset_x == current_root_x &&
msg->pt.y + _gdk_offset_y == current_root_y)
break;
Can someone explain the meaning of "This disturb gtk" - this break in the code causes the following behavior in the application:
if the mouse is over a highlighted widget and the user executes Alt+Tab that shifts to another window on top of the highlighted widget - then, when shifting back with Alt+tab
brings the application into focus without the highlight.
if this a performance hack or does it really prevents a bug in GTK behavior?
Thanks,
Oved
_______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
