Removing object properties is too much of an API break, even for
properties we don't expect to be used outside of GTK itself.
This reverts commit 8b811b623c.
When creating separators we were binding the "label" property on the
tracker to the "label" property on the GtkSeparatorMenuItem.
This was problematic for two reasons.
First, it was pointless. The section header label will never change.
Second, it was causing problems: doing the binding caused the value to
be initially synced up, even if it was NULL. Doing this caused
GtkMenuItem to create a GtkAccelLabel and add it as a child, which
prevented the separator from being shown normally.
Change the code a bit so that we just call gtk_menu_item_set_label()
when creating the item, if we find the label to be non-NULL.
Also, show() the separator item at first. GtkMenu manages visibility of
separators internally, but it seems "more correct" to show it ourselves
at first.
This invariant stopped being guaranteed when we moved the visible area
validation from a high priority idle to a tick callback.
Fixes redrawing bugs like row expanding sometimes not having any visual
effect.
When the search is case sensitive, g_utf8_normalize() is not called, so
the skip_decomp argument of the function forward_chars_with_skipping()
must be FALSE.
To verify that, when searching "éb", the count parameter of
forward_chars_with_skipping() have a different value:
- case sensitive: count = 2
- case insensitive: count = 3 (g_utf8_normalize() has been called)
The commit adds unit tests that didn't pass before, and that now pass
(without known regression, obviously).
https://bugzilla.gnome.org/show_bug.cgi?id=702977
In the non-submenu case we bind the 'visibility' attribute to the
tracker, which takes care of showing the item. In the submenu case, we
don't bind all of the properties, so we miss this one.
Deal with it by just show()ing the submenu item.
https://bugzilla.gnome.org/show_bug.cgi?id=702332
When the file chooser changes directories, it tells the GtkFileChooserEntry to
change its base folder (i.e. the folder from which relative pathnames are resolved).
GtkFileChooserEntry then starts loading a GtkFileSystemModel asynchronously.
In the finished_loading_cb(), however, it would always ask the GtkEntryCompletion
to insert the completion prefix, since that finished_loading_cb() is what is also used
while the user is typing *in the entry*.
But when the entry doesn't have the focus (e.g. the user changed directories by double-clicking
on the file list in the file chooser), there's no reason to insert completions at all.
https://bugzilla.gnome.org/show_bug.cgi?id=672271
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The placeholder string is truncated when there's no
room for it in entry's width.
So, by ellipsizing it, the user can notice the text
was truncated so that they can workaround that by,
for example, maximizing the window.
https://bugzilla.gnome.org/show_bug.cgi?id=702763
The function must return TRUE only if there is a tag toggle _after_ the
iter, not _at_ the iter. So for the end iter, the function must always
return FALSE.
Add also unit tests for gtk_text_iter_forward_to_tag_toggle().
https://bugzilla.gnome.org/show_bug.cgi?id=691266
It was not possible to know if the @limit was for @match_start or
@match_end. It was documented for backward_search(), but not for
forward_search().
https://bugzilla.gnome.org/show_bug.cgi?id=390048
Currently you can only set the current filename, but not
get it. It's useful to be able to get it in save
dialogs, where the user has typed the desired filename
and you are not in a real directory (recent used, for
example).
https://bugzilla.gnome.org/show_bug.cgi?id=702497
By delaying the emission to an idle we avoid a lot of tricky
reentrancy issues. For instance, a normal gtk_icon_theme_choose_icon()
call could in very rare cases (when a user updated an icon theme) emit
a signal which could affect the icon currently being looked up. This
kind of reentrancy is very hard to test against, especially when it is
so rare, so we're better of avoiding it.
There is no real value to get the change signal directly anyway. All
it can do is affect which icon is rendered the next frame, and we will
handle the queued emission before rendering. Not to mention that icon
theme change detection is polled anyway, so it is already delayed.
https://bugzilla.gnome.org/show_bug.cgi?id=694755
When we're reloading the theme in ensure_valid_themes (due to noticing
that a theme dir has changed) we need to also clear the icon cache
as it will not be valid for the new theme.
We already do this in do_theme_change(), but ensure_valid_themes()
was missing this.
https://bugzilla.gnome.org/show_bug.cgi?id=702598
The icon data in GttkIconInfo->data is currently owned by the
IconThemeDir->icon_data hashtable. However, on e.g. a theme change
blow_themes() destroys the dirs and thus the data, meaning any
outstanding GtkIconInfo points to stale data.
We solve this by adding a refcount to GtkIconData and reffing it
from GtkIconInfo.
https://bugzilla.gnome.org/show_bug.cgi?id=702598
GtkBuilder returns GError for _add_from_{file,resource,string}(),
implying that the user should be able to recover from these errors.
Mention in the docs that it's unreasonable to try to do this.
https://bugzilla.gnome.org/show_bug.cgi?id=679930
There's probably an expectation from the app developers that
Ctrl+F or similar common shortcuts for starting a search will
be handled by the widget, when this is not the case. Explicitely
mention it in the docs to avoid confusion.
https://bugzilla.gnome.org/show_bug.cgi?id=701523
