There are some cases where we don't get a WINDOWPOSCHANGE such that
we generate a configure event, even if we called gdk_window_move_resize()
or similar. For instance:
* The window is fullscreen
* The window is maximized
* The specified pos/size is the same as the current one
However, as per X11 ConfigureNotify semantics we *always* want one, or
we could run into issue like e.g. bug #537296 where we're waiting for
the CONFIGURE to call gdk_window_thaw_toplevel_updates_libgtk_only().
We always get the WM_DESTROY message anyway, and we remove it there.
Bug #336416 even claims this could be a leak if the WM_DESTROY
message was not seen before the DestroyWindow call returned, as
the WM_DESTROY message could not be handled later without the
window in the handle table. I'm not sure this can happen, but we
might as well remove it.
There is no particular reason to special case this, we want to handle all
sort of normal events. The only special thing we keep is that
as an optimization we pump the message loop extra during a WINPOSCHANGED
in a modal operation as that will cause us to repaint faster.
Also, bump the arbitrary number of mainloop iterations for the timer.
I don't see why we need it at all, but at least doing more than one
iteration if needed should be nice.
When you start a window resize or move via the window menu and
don't actually change anything we're not getting an exitsizemove.
In order to work around this we also look for WM_CAPTURECHANGED.
This moves all the code from WM_SIZE, WM_MOVE, and WM_SHOWWINDOW into
one place, cleans up the code and makes sure we only send a single
configure event even if both size and position changes.
We don't pass in raise anymore, but already_mapped.
Also, already_mapped must be used rather than MAPPED, as we already
synthesize the MAPPED in the generic code (and thus we don't have
to synthesize it again).
Calling PeekMessage can cause reentrant calls into the window procedure
for sent (as opposed to posted) messages, so its not safe to call
when we're not expecting reentrancy. Instead we call GetQueueStatus
when we're just looking for availible messages.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=552041
By reverting gdk_drag_find_window_for_screen logic to what it was
before eb21a7df29.
The old logic knew how to ignore drag_window when searching
for dest_window, but that code was removed (I guess by accident).
https://bugzilla.gnome.org/show_bug.cgi?id=616544
Commit 5ebb32d1ff didn't add the correct
code to find the toplevel window. The WindowFromPoint() function does
not return the toplevel window in the hierarchy, it returns the deepest
non-disabled, non-invisible child. As we don't use invisible or disabled
windows, we don't actually need to use the ChildWindowFromPoint walk for
the non get_toplevel case, so we can remove that code path.
To find a toplevel, we need to start from the desktop and work up, using
ChildWindowFromPointEx (to ignore invisible and disabled windows). If we
don't ignore invisible and disabled windows (as is the case with the
ChildWindowFromPoint call, we are liable to get returns of hidden or
disabled children of the desktop which don't belong to us, but notionally
occupy the same area under the pointer.
An alternative might be to start our walk with one of the children of the
desktop owned by our process and thread - which we can enumerate using,
the EnumThreadWindows call, or (presumably) determine internally. This
would not work when we are inside a GtkSocket though, as the children of
the desktop would belong to the process owning the GtkPlug - we would
have to rely on our own list of windows.
For correctness, this commit adds tests to ensure that we don't try to
return either x or y window coordinates if that corresponding pointer is
NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=658842
The button highlighting in testgtk works again, even with
GDK_NATIVE_WINDOWS. Unfortunately testgtk:menus still does
not work for the forced-native-window-case.
In _gdk_window_move_resize_child it tries to decide whether to pass
SWP_NOSIZE and SWP_NOMOVE based on whether the new size and position
is different from the window's existing position. However it seems
that GDK now ends up updating the window's position before calling
_gdk_window_move_resize_child so this would mean it would think the
window never changes size or position so SWP_NOSIZE|SWP_NOMOVE would
always be set. This causes child windows to never be resized.
This patch changes it so that it never passes either flag to
SetWindowPos. I don't know whether this will cause any side effects
but you'd think it shouldn't do any harm to reassert the current size.
https://bugzilla.gnome.org/show_bug.cgi?id=628049
Signed-off-by: Hans Breuer <hans@breuer.org>
This way, we can include them without accidentally including deprecated
code. Which means we can still use the recently added turning-off tricks
for deprecation warnings.
Allows more modern browsers eg. firefox 5+ to use gtk/broadway
Auto-detects protocol version, and can switch between them at
as you connect a different browser.
This works to some extent, but seems to hang sometimes, for
instance the "button box" test in testgtk never shows up.
