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).
Previously, GtkWindow would add the "app" action group to its own
toplevel muxer.
Change the setup so that GtkApplication creates the toplevel muxer and
adds itself to it as "app". Use this muxer as the parent muxer of any
GtkWindow associated with the application.
This saves a small amount of memory and will allow for accels to be
propagated from the application through to all of the windows.
With the stock system being deprecated now, we should provide
meaningful accessible names for buttons that are constructed
from icon names or GIcons. This commit reuses the existing
translations.
It is possible that some common icon names are not covered
here because they were not present as stock items. These can
be added to the table later.
Spinners are essentially animated symbolic icons. We don't really
want them being rendered to arbitrary sizes. Also the current
technique for rendering the activity is not suitable for larger
sizes. Until we have a better technique we should limit the size
to the MENU icon size or exactly twice that size.
The 'direction' parameter to gtk_widget_keynav_failed() is based on
gtk_list_box_move_cursor()'s 'count' parameter. However if the passed
in movement is GTK_MOVEMENT_DISPLAY_LINES, 'count' is modified by
the keynav handling and will always be 0. To avoid messing up the
'direction' parameter, use a local variable for keynav handling and
leave 'count' untouched.
https://bugzilla.gnome.org/show_bug.cgi?id=709687
Previous commit wrongly identified "active" as containing the new
value. Instead, applications must determine the new value to
update the model with manually based on the value currently in the
model.
Clarify that applications are expected to handle updating the model
from the 'active' property, like GtkCellRendererText does for the
'edited' property.
If a range goes all the way to the edge of the screen then we don't
have any way to activate autoscrolling. By adding a small region
at the ends of the range we can handle this case. This is the same
approach used in treeviews.
The newly-added gtk_flow_box_child_is_selected() needed to return a
gboolean, so use g_return_val_if_fail() to return FALSE when an invalid
GtkFlowBoxChild* is passed in.
Make flowbox selection more orthodox. Control and Shift now
modify the selection behaviour pretty much in the same way
they do in a tree view, and clicking without modifiers will
clear the selection.
When dealing with touch devices, we treat modifier-less events
as modifying the selection.
This commit also adds a few other selection necessities, such
as catching Escape key presses to cancel rubberband selection,
and handling grab notify.
GtkFlowBox is a container that its children in a reflowing
grid, which can be oriented horizontally or vertically.
It is similar to GtkListBox in that the children can
be sorted and filtered, and by requiring a dedicated child
widget type, GtkFlowBoxChild. It is similar to GtkTreeView
in that is supports a full set of selection modes, including
rubberband selection.
This is the culmination of work that has happened in the
egg-list-box module, and earlier in libegg. The origins of
this code are the EggSpreadTable in libegg, which was written
by Tristan van Berkom. It was moved to egg-list-box and
renamed EggFlowBox by Jon McCann, and I gave it some finishing
touched in the flowbox-improvements branch of that module.
Previously, the "Places" sidebar was populated by the update_places()
call from within gtk_places_sidebar_style_set(). After
742a2f11a9, update_places() is never called
and the sidebar is never populated unless gtk_places_sidebar_add_shortcut()
happens to be called. This commit fixes this by calling update_places()
at the end of gtk_places_sidebar_init().
https://bugzilla.gnome.org/show_bug.cgi?id=709522
GtkWidget had a hack where if opacity is 0.999 we set up an opacity group when
rendering the widget. This is no longer needed in 3.10, and GtkStack doesn't
use it anymore.
GdStack is using it, so applications should be ported from GdStack to GtkStack
in 3.12.
https://bugzilla.gnome.org/show_bug.cgi?id=703603
Resize modes don't work anymore, both because nobody ever uses them and
because the frame clock changed the way things work quite a bit. So we
don't want to advertise them as a good idea.
https://bugzilla.gnome.org/show_bug.cgi?id=708787
