It would default to GTK_FILE_CHOOSER_ACTION_OPEN if the user's specified --action could not be
parsed. I can never remember what the right options are, so make the program bail out
if the user specifies an unrecognized option.
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 file chooser does not show the hours for files modified today
when using it & hu locales on Win32. This is due to the %k format conversion
for strftime() that is in Olson's Timezone Package, which msvcrt.dll doesn't have.
Cygwin has it, though.
So for now, we just use a %H format. While %k would render
six-in-the-morning as " 6" (6 preceded by a space), %H will render it
as "06".
https://bugzilla.gnome.org/show_bug.cgi?id=560337
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
and not on each keystroke, which for some IMs apparently caused a full
update on each keystroke, not just a check for changes. Patch from
Takuro Ashie, bug #698183.
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
