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.
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.
Fix clipping of drawn pixbufs in the no-render case
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.
Remove broken logic in backwards walks in validate_visible_area()
In validate_visible_area() it was assumed that gtk_tree_path_prev()
would always return the correct path of the preceding node. This is
obviously not true. The if-clause has been removed so that we now
always use _gtk_tree_view_find_path() to get the path from the tree,
node.
Bug 526149 - GtkCellRendererAccel editing conflicts with mnemonics
GtkCellRendererAccel also needs to acquire the GTK+ grab in addition to
a GDK keyboard grab. With the GDK keyboard grab, KeyPress and
KeyRelease events are delivered as usual, although we only want to
receive them for our grab widget.
Bug 478519 - GtkTooltip segfaults on NULL gdk-display-current-tooltip
Make the tooltip code a bit more robust for a case that only occurs when
GTK+ is used from a language binding. It looks like this case appears
because the memory management / ref counting is handled differently in
some of the language bindings. Instead of asserting, we will fail
silently. Also fix a think-o in gtk_tooltip_start_delay(). Patch from
O. Andrieu.
The previous code would trigger on an unmodified 'S' key for a
'Super+S' accel. The current code avoids that at the cost of breaking
combinations like 'Mod4+Super+S' which are too exotic to worry about...
Bug 591526
Paolo Borelli [Mon, 17 Aug 2009 15:04:30 +0000 (17:04 +0200)]
Bug 592003 - Shift+click should always modify selection
Shift-click inside an existing selection reduces the selection to the
range from the insert mark to the clicked point instead of removing the
selection. This makes GtkTextView more consistent with GtkEntry.
Fix gdk_window_get_geometry for native children with non-native parent
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).
Always queue antiexposes after flushing outstanding moves
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.
Tor Lillqvist [Thu, 13 Aug 2009 19:49:35 +0000 (22:49 +0300)]
Initialize missing methods on Windows
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.
Make _gdk_window_process_updates_recurse reentrancy safe
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)
Ensure that queue_translation is paired with the right X operation
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.
Modify window system exposes wrt outstanding moves
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.
Don't un-invalidate area that will be immediately invalidated again.
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).
Benjamin Otte [Thu, 6 Aug 2009 14:25:20 +0000 (16:25 +0200)]
Bug 590959 - Set child_has_focus flag properly (second try)
Previously, this flag wasn't cleared properly when the notebook lost
focus, but only when the notebook was focussed again later.
As this flag is only used to advance correctly focus pages by grabbing
focus to the new page after switching the page, this is not good.
In particular, it can cause a focus grab when programmatically switching
the notebook page and the focus is inside a completely different widget.
projects / ~andy / gtk / log