The previous implementation was modifying the passed in window ("private") rather than deriving information from it. Also the type hints are now forwarded like in the X11 implementation instead of ignored.
The effect of the unfinished client-side-window porting was e.g. a crash with Dia's navigation window which happened to create a window with an apparent depth of zero.
When we just invalidate some area from the app we don't need to clear
windows with no exposure mask, because that wouldn't have happened pre-csw
anyway. Additionally we can avoid such clearing for native windows in cases
where the xserver already did the clearing like on exposes or when resizing
toplevels.
This means we don't fully redraw a GtkSocket when it resizes, thus
avoiding flicker in gnome-mplayer as reported in this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=598050
(cherry picked from commit 9e51c10edc)
Backends that support native window background setting (and that clears
new window areas to this color/pixmap) should set this to true.
Currently only X11 supports this.
(cherry picked from commit 39993f147f)
When moving or scrolling a window with native children, there is no
need to expose the areas that are copied by the windowing system
as part of moving/resizing the native windows anyway.
(cherry picked from commit 4cd5c98942)
Clearing will directly modify the contents of the window, so we need
to flush any outstanding moves or double-buffering.
(cherry picked from commit 8c1ea38d84)
The root window width and height have already been correctly
initialised in _gdk_root_window_size_init() to cover all monitors, so
don't incorrectly re-initialise using GetSystemMetrics(SM_C[XY]SCREEN)
which only gives the size of the primary monitor anyway. (See MSDN.)
This fixes at least gdk_screen_get_{width,height}() which indirectly
affects at least the positioning of combo box pop-up menus on multiple
monitors.
We need to do a final XQueryWindow to get the coordinates inside the
windows rather than in the parent window.
This fixes bug #597386, "Cannot click buttons more than once...", which
failed due to the grab tracking stuff getting the wrong coordinates as
per the above.
Thanks gcc :
gdkwindow-x11.c:1731: warning: passing argument 3 of
'XReconfigureWMWindow' makes integer from pointer without a cast
/usr/include/X11/Xlib.h:1871: note: expected 'int' but argument is of
type 'struct GdkScreen *'
Signed-off-by: Pascal Terjan <pterjan@mandriva.com>
These event types propagate up the hierarchy anyway, so this means
we avoid setting it unnecessarily. This is especially important
for button press event, since only one client can select for this
on each window, causing X errors if two clients do it.
This detection code is not 100% reliable, but it should fare much better
than the current code, which just compares the device name to a fixed
set of strings. Many applications depend on erasers being recognized
reliably, so we start by checking for a device name containing the
substring 'eraser'.
Signed-off-by: Thomas Jaeger <ThJaeger@gmail.com>
This has two advantages:
1) In many backends, this is faster as we can terminate the window
hierarchy traversal earlier
2) When used in gdkdisplay.c::get_current_toplevel() to get the
current toplevel that has the pointer we now correctly return
a toplevel with the pointer in it where the pointer is inside
some foreign subwindow of a toplevel window.
The second advantage fixes some bugs in client side event generation
when the pointer is inside such a foreign child window.
Based on first patches by Christian Hergert. Change
screen_get_monitor_geometry() so that it translates the layout of the screens
from Cocoa layout to GDK layout. In Cocoa, the screen locations
are specified in Cocoa geometry, as well as that GDK uses a different way
to place individual monitors in the root window. For now only monitors
that are laid out horizontally are supported (see the FIXMEs in the source),
in bug 596238 we will track future work to get things fully right.
Modify _gdk_quartz_window_get_inverted_screen_y() to take the differences
in screen layout between Cocoa and GDK into account. Also this function
is subject to future work.
Explicitly handle resizing by leaving all events in the lower right 15x15
corner to Cocoa, if the window shows a resizing indicator. Some
applications may have widgets allocated in this area. Generally, these
widgets are likely larger than 15x15 so they can still be hit. Often
scroll bars are found in this area and these can also be manipulated by
other means. Since this is the only way of resizing windows on Mac OS X,
it is too important to keep it broken.
When we grab the pointer we need to request more events than what is
specified, otherwise our event emulation stop working and you won't
e.g. get crossing event unless you specified motion event mask.
F-Spot needs this as it draws on a foreign (screensaver) window, which
used to work.
I believe this is safe, because in all typical cases the expose
mask will not be set, so we won't do anything, and its what we used to
do.
Make the quartz backend support the new queued translations. We do this
by keeping our own copy of the region that has been set to need display.
Using this region we can intersect by the given area, translate this and also
set needs display for the resulting area.
When filtering out the events for "window" from the events we got for
our "impl_window", don't forget to adjust the returned number of
events because it might be smaller than what XGetMotionEvents has
returned, and free coords we allocated too much. Also if we filtered
away *all* events, return FALSE and get rid of the allocated history
entirely. Together fixes all sorts of mishehavior when painting in
GIMP, from coords going wild to plain crashes and infinite loops.
On startup, the root window got assigned the size of the main screen.
But, the GdkScreen has the width of all screens/monitors connected to the
machine. Change this so that in _gdk_windowing_window_init, we assign
the width/height of all monitors to the root window width, height.
Should fix bug 594738.
