Make gtk_tree_view_real_set_cursor() handle non-existing paths
Such paths (eg. a child node that is collapsed) should be ignored. This
is fixed by checking the return value of _gtk_tree_view_find_node(),
which returns a partial return value (the parent node) when it returns
TRUE. Also added a unit test.
Bug 543310 - set_enable_tree_lines doesn't work when a cellrenderer...
Reorder drawing in gtk_tree_view_bin_expose() so that the tree lines are
drawn after the cells have been drawn. This is because cell-background
is handled in the cell renderer, so the tree lines need to be drawn
after this.
Bug 588199 - GtkTreeView rendering glitch while using a default ...
Contrary to what was believed before, do_validate_rows() does need to
queue a normal resize (including a redraw) when it has to. The redraw
is required because of the size of the tree has changed because new
row(s) have been validated.
Bug 592883 - Spin cell rendererer problem with double click
Block 2BUTTON and 3BUTTON press events using a button press event
handler in GtkCellRendererSpin, so that they won't be eaten and
processed by tree view.
Benjamin Otte [Fri, 21 Aug 2009 17:02:38 +0000 (19:02 +0200)]
Bug 592606 - Activate the default button in a respose-request callback
Previously the rightmost button with a proper response id was activated,
this is now only done if there is no default button set.
With this patch the right widget gets activated when there are multiple
widgets wth response ids conforming to is_stock_accept_response_id() as
the selected widget is made the new default widget before showing the
overwrite confirmation dialog.
Don't unnecessarily set the event mask as that can cause X errors
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.
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).
projects / ~andy / gtk / log