If a menu is opened and it doesn't fit entirely below or above
the menu bar, gtk+ will place it on top. The button release will
then activate the popup item that happens to appear under the
cursor. Avoid this by ignoring release events if they originated
in the parent menu bar and the duration of the press was too short.
https://bugzilla.gnome.org/show_bug.cgi?id=703069
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
