Call gtk_cell_layout_clear() on the area instead of the completion in
gtk_entry_completion_clear_text_column_renderer(), because it is also
called from within gtk_entry_completion_clear().
gtk_entry_completion_set_text_column() always added a cell renderer,
regardless of whether there was an existing one already installed. This
patch reuses an old renderer if it exists, but only if it was added by a
previous call to this function.
To avoid conflicts, all renderers that were added manually are removed
when calling this function. Also, the renderer added by this function is
removed when manually adding new renderers. This effectively gives
GtkEntryCompletion two modes (managed and manual cell renderers) and
allows seamless switching between the two.
This is a minor API break. However, this shouldn't be an issue in
practice as applications couldn't call set_text_column() more than once
because of this bug. Also, it is unlikely that many applications mix
set_text_column() and custom cell renderers. The interaction between the
two modes was erratic and not documented well.
https://bugzilla.gnome.org/show_bug.cgi?id=635499
Call gtk_entry_completion_set_text_column() when setting the
"text-column" property directly.
The completion appeared empty when setting "text-column" directly (for
example from a GtkBuilder file), because the setter creates and adds the
GtkCellRendererText.
https://bugzilla.gnome.org/show_bug.cgi?id=710533
The MINMAXINFO struct was being populated based upon geometry hints when
GDK_HINT_MAX_SIZE flag was enabled, then promptly having its values blown
away with default values.
https://bugzilla.gnome.org/show_bug.cgi?id=711110
_gtk_widget_draw_internal() was clipping by passing the subwindow
sizes as a path to cairo_clip(). This was breaking for windows
larger than 23 bits in width/height, due to cairo using fixed point
(24.8) for the path coordinates.
We fix this by pre-clipping the subwindow region to the existing
cairo clip region in the full 32bit gdkwindow precision. This fixes
the GooCanvas Large Items test.
https://bugzilla.gnome.org/show_bug.cgi?id=710958
I have been convinced that it is a bad idea to change the behaviour
at the same time as deprecating it, so go back to respecting the
Gtk/ButtonImages xsetting in buttons created with
gtk_button_new_from_stock() when it is set.
The setting as well as the function are still deprecated, and the
default value of the setting will remain FALSE.
I have been convinced that it is a bad idea to change the behaviour
at the same time as deprecating it, so go back to respecting the
Gtk/MenuImages xsetting in GtkImageMenuItem when it is set.
The setting as well as the widget are still deprecated, and the
default value of the setting will remain FALSE.
Since 49c4ad2f the order between "Page_Down" & "Next" had been changed (due to
sorting) and this resulted in the Page Down key being identified as "Next"
instead of "Page_Down"
"Page_Up" wasn't affected, since it comes before "Prior"
Signed-off-by: Olivier Brunel <jjk@jjacky.com>
https://bugzilla.gnome.org/show_bug.cgi?id=710411
The tick callback IDs from GtkWidget aren't timeouts, so
use the correct function to disconnect from them.
Spotted by Benjamin Otte <otte@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=710666
For some widgets, like GtkTreeView, which setup a clock frame
update during realize, it was possible to call
gdk_frame_clock_begin_updating() twice, but only ever disconnecting
from it once. This happens because the realized flag is set at an
unpredictable time by the GtkWidget's realize implementation.
Keep the signal handler ID from us connecting to the "update" signal
to avoid connecting to it twice.
This fixes high wake-up count from any application using GtkTreeView,
even idle ones.
https://bugzilla.gnome.org/show_bug.cgi?id=710666
