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.
The quartz backend simulates the semantics of XGrabPointer, as a part of
this it checks the event mask of the grab. However, implicit grabs on X
do not go through XGrabPointer and thus the quartz backend should not check
the event mask for these. This fixes various "the UI got stuck" cases.
If we move, resize or otherwise change a window from inside a (double
buffered) expose handler we can run into issues with double buffered
paints that have already been ended but have not yet been commited
to the window from the implicit paint pixmap.
For instance, any copies of source regions due to a window scroll need
to take these into account, and any operation that causes some drawing at
a destination covered by the implicit paint region would be overdrawn
when the implicit paint is ended.
So, before we do any window-hierarchy changing operation while an implicit
paint is in effect we flush all moves and already commited paints.
When a window is moved or resized from a double-buffered expose handler
we can't really just copy the window region around, as the window
will be overdrawn with the double buffered region when the expose returns.
Instead we remove all regions with outstanding implicit paints from the
region to be copied and just mark this area as invalid to be redrawn
later.
This fixes bug 594880.
Its not correct for recurse gdk_window_process_updates_internal, as
the outer instance will overdraw the inner. So, protect against
gdk_window_process_updates() being called while in an expose
handler.
This shouldn't be a repaint problem, as eventually the idle handler
will cause the updates to be processed.
We used to handle zero height/width specially in the non-double buffered
case due to the weird behaviour of XClearArea in this case. However
this is undocumented, incompatible with what happens on double-buffered
drawing, and just not a good API. So, we drop this behaviour, having
fixed gtkclist.c which used this.
There are two issues here. First of all an ignored update didn't
use to unset update_idle which could cause all further idle repaints
to be ignored. (Bug #591583)
Secondly, if we ignore the process_all_updates we may end up not updating
the windows in update_windows unless something else triggers an update.
So, we handle this by checking for recursions and scheduling a new update
at the end of the outermost process_all_updates.
The check for a possible implicit paint flush before queueing an
antiexposure was wrong. An implicit flush doesn't actually NULL
the implicit paint, se we have add a flag to explicitly track if
it is flushed.
Passing region into _gdk_gc_set_clip_region_internal takes ownership,
so don't use it after that. We can just as well just move the usage
above the call.
Generally you only need to work around bugs in one specific app, so we
don't want to affect the applications that application will start.
Thus we unset GDK_NATIVE_WINDOWS after reading it.
For toplevels, never apply clip as shape, instead apply shape.
This way we don't have to re-set it all the time as the window size
changes. Furthermore, this change fixes unsetting a shape on a
toplevel window which didn't actually unset the shape before.
Additionally we never apply clips as shape if the shape would just
be the same as the regular window size. This means we won't unnecessarily
add a useless shape to most native child windows (and additionally this
helps apps that do weird X stuff that don't expect these shaped windows).
I.e. we use:
impl_iface = GDK_WINDOW_IMPL_GET_IFACE (private->impl);
And then use impl_iface instead of the full macro when calling vfuncs.
Also, in some places we avoid getting the iface multiple times.
For instance, two clients selecting for button events can cause BadAccess.
This fixes bug 592624, where a gdk_window_reparent caused us to re-set
the event mask, breaking the workaround for the mozilla BadAccess bug.
When updating the clip region on cairo context (due to window changes or
paints of different sizes) we reset the old clip region, but this was
erronously done inside a cairo_save/cairo_restore pair, which made the
reset not take effect.
This fixes bug #592263.
Instead of doing some magic in gdk_draw_drawable() to avoid double
offsetting when calling gdk_draw_drawable on the impl we call
the vfunc directly on the impl. Thus removing the weird magic from
gdk_draw_drawable().
I tested this with the testgtk test "text", where if the original magic
code is disabled typing a newline in the middle of a text line causes
the double offset issue to appear.
When the clip mask is completely inside the drawable clip region we
don't change the clip at all. However, we did set region_tag_applied,
so when the drawable clip was removed we removed the original clip mask.
This is no good, so we fix that by returning early in this case.
Fixes issue reported in bug #592752.
The fallback pixbuf rendering case ends up calling gdk_draw_image() on the
destination drawable wrapper, which resets the previously set clip region.
So, we need to manually get the impl and draw on that directly.
This fixes bug 592752 where we don't clip pixbuf rendering on non-render
Xservers.
Some applications make weird assumtions on Gtk+ that do not work anymore
with the new client-side windows support. For instance SWT/Eclipse reorders
the stacking order of the X windows directly without telling gdk this,
which breaks gdk drawing as gdk now relies on knowing the stacking order
for window clipping.
This introduces a GDK_NATIVE_WINDOWS environment variable, which if set
causes Gtk+ to always use native windows. Its more compatible with
pre-csw Gtk+ behaviour if you do weird X-specific hacks, although it does
limit the size of GdkWindows to 65535x65535.
gdk_window_get_geometry calls the native function for all non-native
windows. This returns coords relative to the native parent. We need
to convert this to be relative to the client side parent.
This fixes DnD coordinates in firefox (bug 588437).
If antiexposures are queued and then we do the outstanding moves
we will queue translations that will affect incomming exposes
wrongly wrt the antiexposure. So, make sure we process the outstanding
moves before doing the antiexposure.
Additionally this commit adds a bunch of comments about how the
expose handling works and fixes a small bug that made us always
flush outstanding moves a little to early than necessary.
Set the input_window_destroy and input_window_crossing methods of the
GdkWindowImplIface on Windows. Add implementation of
_gdk_input_crossing_event that is mostly dummy, though.
Apps may change the window hierarchy while recursing over it by
destroying windows from the expose event handler. We need to copy
the children list and ref all the children while recursing.
This fixes some crashers in gedit (bug #589367, bug #591434)
The X11 queue_translation operation uses NextRequest to get the serial
of the XCopyArea operation where the translation should end. However,
if the gc passed to gdk_draw_drawable has a non-flushed clip region
(which it commonly has now for the window clipping) then the next
operation will be the GC flush, not the XCopyArea.
To handle this right we now pass in the GC to be used to
queue_translation and ensure that it is flushed before calling
NextRequest().
When we copy the region we need to also re-expose the areas of
the copied region that was not also in the destination.
And, we need to do this invalidation after the move, as the
move also moves any invalid area.
If there are outstanding moves in an area that intersects
the source of an outstanding move we need to move the invalid
area correspondingly, otherwise we will expose the wrong area
as the outstanding move copy will happen before we expose
the invalid area.
When moving an area we move any invalid region in this area to the
new place, but there really is no need to remove the old invalid
area as it would just be invalidated again (being newly exposed).
This extends the usage of the native clear region call such that its
called also for windows that have parent relative background all the
way up to a native window. That way we get true background relative
background clearing even to a foreign parent, which means that some
transparent notification icons look right again.
GdkDrawable->draw_drawback was replaced with a new vfunc
draw_drawback_with_src that is now called from gdk_draw_drawable.
However, some code seems to call the vfunc directly (see bug #591288),
so make it chain to the new call.
Note that such direct vfunc calls are a bad idea and won't work for all
cases.
This moves the native show/hide calls to the generic code
for calculating viewable rather than in its own separate code
called from gdk_window_show/hide. This simplifies the code a bit,
but most significantly it means things are correctly shown when
they become viewable for other reasons than a show/hide call.
For instance, this fixes bug 590442 (gvim embedding) where the
toplevel GtkPlug is mapped by the embedder and we didn't previously
pick up that the native children became viewable and should be shown.
We used to invalidate the whole window when raised, but this is
unnecessary much, we now just invalidate the visible area minus the
previously visible area.
This also fixes a problem where expose calling raise caused a loop (#588438)
This never worked before csw since the root window is never
set as IS_MAPPED, but with the new viewable check (which is
true for the root window) we could erronously queue exposes
on the root window.
This happened unexpectedly in bug 589369, where metacity
got a GraphicsExpose event on the root window due to some
graphics operation, queueing an expose which would be handled
by clearing that area. That is fixed with this commit.
This seems to more or less fix the build. On Tiger there are still issues
with libresolv missing on the link line, I will figure out what's up with
that soonish.
We get the real pixmap size and use as cairo surface size rather
than doing some magic to try to get clipping on the right hand size
(and the magic looks wrong anyway).
The previous code could result in the width/height being to big for
the cairo 28.4 fix point size and thus not drawing anything.
This fixes bug #588076.
When the fallback for gdk_draw_pixbuf (gdk_drawable_real_draw_pixbuf)
is called with a window destination we have already applied any clip
regions and offsets for the window, but the window we get is a wrapper
and not an impl. We have to ensure we really draw to the impl, as
otherwise the pixbuf drawing will be clipped by client side subwindows.
This fixes bug 588553.
gdk_window_input_shape_combine_mask() can accept NULL for the mask
parameter, but it wasn't checking for NULL before passing the
resulting GdkRegion to gdk_region_destroy(). Fixes#589275
