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
_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.
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
This is what we used to get through the Net/FallbackIcontheme
setting. Nobody has ever set this setting to a different value,
and people have come to rely on GTK+ applications getting their
icons this way.
The objective is simplify the semantics of the code so that we don't
need to check for "(iter != NULL && !g_sequence_iter_is_end (iter))"
in the callers.
With style BOTH_HORIZ the label would not be selected (if not marked
"important") and when there's no icon, it would result in an empty button.
Signed-off-by: Olivier Brunel <jjk@jjacky.com>
https://bugzilla.gnome.org/show_bug.cgi?id=710134
When doing fallback for symbolic icons, we first shorten
the name at dashes while preserving the -symbolic suffix.
But after exhausting that, we should also try stripping
the suffix.
https://bugzilla.gnome.org/show_bug.cgi?id=708163
When showing a tooltip on the edge of a monitor, the tooltip could be wrongly
placed and be shown going from one monitor to the next.
This happened because the current_window wasn't set visible, and when it wasn't
the returned allocated size would be 1, hence wrong calculations.
Signed-off-by: Olivier Brunel <jjk@jjacky.com>
https://bugzilla.gnome.org/show_bug.cgi?id=698730
Rework how accels are handled on GtkApplicationWindow.
Instead of having GtkApplication fill the GtkAccelMap which is then used
by GtkApplicationWindow to create a GtkAccelGroup filled with closures
that is then associated with the window, do it directly.
GtkApplication now keeps a list of accels and their actions.
Accelerators on a GtkApplicationWindow ask GtkApplication to execute the
appropriate action.
This saves a fair bit of complexity and memory use (due to not having to
create all those closures and accelmap entries). The new approach also
supports multiple accels per action (although there is not yet a public
API for it).
This patch (and the ones before) Reviewed and ACK'd by Matthias Clasen.
Add support for pulling the primary accel out of the GtkActionMuxer.
With this change, it is no longer necessary to have the accel=''
attribute hardcoded onto each menu item (and, in fact, it should be left
off if you intend to have support for dynamic accelerator changing).
Specifying accel='' is a good way to force an accelerator not to be
displayed on a menu item.
Store "action and target" format inside each GtkMenuTrackerItem. This
makes action invocation more efficient (no hash table lookups or
allocations) and slightly simplifies handling of action namespace.
More importantly, this will be used when we start to get accels from
GtkActionMuxer.
Reuse the existing infrastructure in GtkActionMuxer for propagation of
accelerator information: in particular, what accel label ought to appear
on menu items for a particular action and target.
This is a good idea because we want accels to travel along with the
actions that they're tied to and reusing GtkActionMuxer will allow us to
do that without creating another hierarchy of a different class for the
sole purpose of filling in accel labels on menu items.
Doing it this ways also allows those who copy/paste GtkActionMuxer to
insert the accels for themselves.
Add a new method on the GtkActionObserver interface to report changes.
This patch introduces a new concept: "action and target" notation for
actions. This format looks like so:
"'target'|app.action"
or for non-targeted actions:
"|app.action"
and it is used over a number of possible alternative formats for some
good reasons:
- it's very easy to get a nul-terminated action name out of this format
when we need it, by using strrchr('|') + 1
- we can also get the target out of it using g_variant_parse() because
this function takes a pointer to a 'limit' character that is not
parsed past: we use the '|' for this
- it's extremely easy to hash on this format (just use a normal string
hash) vs. attempting to hash on a string plus a GVariant
A close contender was to use detailed action strings here, but these are
not used for two reasons:
- it's not possible to easily get the action name or target out of the
strings without more work than the "action and target" format
requires
- we still intend to use detailed action strings on API (since they are
a lot nicer to look at) but detailed action strings can be given in
non-canonical forms (eg: 'foo::bar' and 'foo("bar")' are equivalent)
so we'd have to go through a normalisation step anyway. Since we're
doing that already, we may as well convert to a more convenient
internal format.
This new "action and target" format is going to start appearing in a lot
more places as action descriptions are introduced.
I suspect that nobody is using '|' in their action names, but in case I
am proven wrong, we can always switch to using something more exotic as
a separator character (such as '\x01' or '\xff' or the like).
