When state-hint is TRUE, GTK_STATE_ACTIVE was used to paint the entry
background and frame, since commit
207f3f8685.
Given that everywhere else in GTK2 - including GtkEntry itself in
draw_text_with_color() - GTK_STATE_ACTIVE is used for non-toggleable
widgets to indicate selected but not focused text, this leads to the
entry painting itself with the wrong background color when focused.
This is unsolvable from the theme, as changing the ACTIVE background
color to be the same as NORMAL would give a wrong background to selected
but not focused text as per above.
This patch avoids using GTK_STATE_ACTIVE to paint GtkEntry's background,
changing the code so that the widget state is always used instead.
https://bugzilla.gnome.org/show_bug.cgi?id=692554
Add _gtk_button_event_triggers_context_menu() and use it instead
of checking for event->button == 3, so context menus are invoked
correctly on the Mac.
which are SHIFT and MOD2 on the Mac, and SHIFT and CONTROL otherwise.
Use the new define all over the place and rename variables and
members to not say "shift" or "control".
The gdk_drawable_ accessors were deprecated. Removes a lot of
compile-time warnings and eventually also makes things work again
on Mac (miscompile due to the missing prototypes).
The following style properties are there to let theme engines 'opt-in'
to more correct behaviour while maintaining compatibility with existing
themes. GTK+ 3 engines are expected to handle the more correct behaviour,
and these properties will no longer be there in GTK+ 3:
GtkEntry::state-hint
GtkTreeView::row-ending-details
GtkRange::trough-side-details
GtkRange::stepper-position-details
GtkRange::activate-slider
Also, added api to allow an input method to internally handle
key press and release events in the GtkTextView and GtkEntry
cases.
This is simply a wrapper to the gtk_im_context_filter_keypress()
function, but It's added to not access the ->im_context
directly.
Based on a Christian Dywan patch
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=163251
New patch makes sure to update the display even when
the GtkEntry's buffer is set to NULL, it also breaks the
reference to the buffer in ->dispose() instead of ->finalize().
This commit was created using a script that searched for all docstrings
containing a parameter and the string 'or %NULL'.
Gdk backends and demos excluded as they are not part of a public API
https://bugzilla.gnome.org/show_bug.cgi?id=610474
The Gtk-custom.c file in gir-repository contained a number of
introspection annotations. Merge those into the GTK source files.
Some documentation was moved from the tmpl/ files to accomodate
the addition of annotations.
GTK_ENTRY()->editing_canceled should really have been a parameter of the
GtkCellEditable::editing-done signal, it should be a property on the cell
editable interface
https://bugzilla.gnome.org/show_bug.cgi?id=594962
progress-border and invisible-char style properties had wrong amount
of colons for gtk-doc (signal markup instead of properties), so the
Since tags didn't seem to get picked up.
GtkEntry:invisible-char also had a wrong Since: 2.22, fixed to 2.18.
To fix this I replaced the code that creates an internal buffer
at init and construction time with code that creates a buffer
at _get_buffer() time, this is the same as GtkTextView does and
fixes the crashes for me.
