Fellow gtk-win32 hackers: please test this
- From: Tor Lillqvist <tml iki fi>
- To: gtk-devel-list gnome org
- Subject: Fellow gtk-win32 hackers: please test this
- Date: Thu, 17 Mar 2005 01:21:31 +0200
In order to make gtkplug/socket (widget embedding) work on Win32, I
think I'll have to remove a couple of very old code snippets relating
to event generation from gdkevents-win32.c. I would like people to
verify that removing them doesn't cause any bad effects...
1) Currently WM_MOUSEMOVE messages are ignored (and no GDK events
generated) if the process in which the GDK event loop in question runs
doesn't own the current active window. (This breaks event generation
in embedded widgets somewhat, enter/leave events don't get
synthesized, prelighting doesn't occur, menus don't work correctly.)
Some digging through CVS shows that there has been a comment relating
to this that said:
Try hard not to generate events for windows that shouldn't get any.
This is hard because we don't want pushbuttons to highlight when the
cursor moves over them if the window is inactive. We dont want
tooltips windows to be active. OTOH, also menus are popup windows,
but they definitely should get events. Aw shit. Skip this.
and some code was in #if 0, but then later the current approach with a
active window ownership check was introduced.
Anyway, I don't know how important it actually can be not to generate
events for inactive window. I don't think there is any direct
equivalence to Win32's "active window" concept in X11, but anyway, if
you move the cursor over GTK buttons in X11 they prelight even if the
GTK app in question doesn't have focus, so it can't be that bad.
2) Currently WM_MOVE messages (window location has moved) are ignored
for non-visible ("unmapped") windows. (This breaks the "local passive
child" test in testsocket. The plug window (for some reason I don't
understand) is moved outside of the socket window when reparented (see
the gdk_window_reparent() call in _gtk_plug_add_to_socket()), and we
don't notice this in GDK as the window is still unmapped and thus no
gdk events are generated.)
Anyway, the diff is below. I would be grateful if the gtk-win32
hackers could try this out with their favourite torture test
apps... Thanks.
--tml
Index: gdkevents-win32.c
===================================================================
RCS file: /cvs/gnome/gtk+/gdk/win32/gdkevents-win32.c,v
retrieving revision 1.147
diff -u -2 -r1.147 gdkevents-win32.c
--- gdkevents-win32.c 16 Mar 2005 02:21:14 -0000 1.147
+++ gdkevents-win32.c 16 Mar 2005 22:49:58 -0000
@@ -2139,6 +2139,4 @@
gint *ret_valp)
{
- DWORD pidActWin;
- DWORD pidThis;
RECT rect, *drag, orig_drag;
POINT point;
@@ -2706,10 +2704,4 @@
GET_X_LPARAM (msg->lParam), GET_Y_LPARAM (msg->lParam)));
- /* HB: only process mouse move messages if we own the active window. */
- GetWindowThreadProcessId (GetActiveWindow (), &pidActWin);
- GetWindowThreadProcessId (msg->hwnd, &pidThis);
- if (pidActWin != pidThis)
- break;
-
assign_object (&window, find_window_for_mouse_event (window, msg));
@@ -3296,6 +3288,5 @@
if (GDK_WINDOW_TYPE (window) != GDK_WINDOW_CHILD &&
- !IsIconic (msg->hwnd) &&
- IsWindowVisible (msg->hwnd))
+ !IsIconic (msg->hwnd))
{
if (!GDK_WINDOW_DESTROYED (window))
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]