Keyboard activation relies on the menu not being visible,
so ensure that it isn't when the menu is attached.
Problem tracked down by Vincent Le Garrec,
https://bugzilla.gnome.org/show_bug.cgi?id=688738
The rsvg loader now restricts what external files it will
allow to load from an svg. Thus our xinclude trick doesn't work
anymore. To work around that, embed the payload in a data: uri.
This is somewhat ugly, but the best we could come up with.
Just as for GtkRangeAccessible, we were not even trying to disconnect
the signal handler from the adjustment. The same fix works here:
override the widget_set and widget_unset vfuncs.
https://bugzilla.gnome.org/show_bug.cgi?id=705692
We were only disconnecting the signal in finalize, when
the widget was already unset. Instead, override the widget_set
and widget_unset vfuncs of GtkAccessible, and keep a reference
to the adjustment.
https://bugzilla.gnome.org/show_bug.cgi?id=705692
Applications have no way of finding out if a session manager proxy was
successfully created in gtk_application_startup_session_dbus(), so it's not
appropriate for certain public GtkApplication functions to be asserting the
presence of a session manager proxy as if it were a programmer error.
This affects:
gtk_application_inhibit()
gtk_application_is_inhibited()
If sm_proxy is NULL, the function should just return silently.
In the case of gtk_application_uninhibit(), the application should only be
calling this if it obtained a valid cookie, which implies the presence of a
session manager proxy. I noted that with a comment.
https://bugzilla.gnome.org/show_bug.cgi?id=701365
Move the call to gdk_x11_atom_to_xatom_for_display() outside of the
search loop in gdk_x11_screen_supports_net_wm_hint(). In my test case
(running Audacious for about a minute), this reduced the total number of
hash table lookups performed from 370,000 to 230,000.
https://bugzilla.gnome.org/show_bug.cgi?id=702913
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
GtkAssistant supports not showing the sidebar with the page
titles (if the page have no titles). Unfortunately, we were
hiding the sidebar in this case, but still rendering the frame
behind it, leading to a broken appearance.
Commits the pre-edit string on receipt of focus_out and reset
commands.
Patch refinements by Cody Russell <bratsche@gnome.org> and
Ek Kato <ek.kato@gmail.com>
(cherry picked from commit e8b6b806250c1f958c33920c60ed41ab88016767)
We checked for G_IS_LOADABLE_ICON() before GDK_IS_PIXBUF().
Since we made GdkPixbuf implement GLoadableIcon, the special case for
pixbufs is never used, and the much much slower GLoadableIcon path is
taken instead. Move the GdkPixbuf one to be first to fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=705320
When an application translates a key event and drop its native event
before passing to imquartz, it can't recognize the NSEvent. On this
case imquartz doesn't emit any signals such as "commit" signal so
that the application doesn't insert any text. To avoid no response,
at least imquartz should fallback to slave GtkIMContextSimple.
https://bugzilla.gnome.org/show_bug.cgi?id=694273#c27
(cherry picked from commit c064e18894)
Plug windows weren't redrawing properly because the embedded
window was expecting to get messages for each frame from the
compositor, but the compositor doesn't know about embedded
windows. Simply disable frame sync for GtkPlug's GdkWindow -
extending XEMBED to handle frame sync isn't interesting
at this point.
A new API gdk_x11_window_set_frame_sync_enabled() is added
to allow this to be done.
https://bugzilla.gnome.org/show_bug.cgi?id=701613
This patch can be considered a leftover of commit 12ffae5,
replace the no longer existing function with the GDK function
meant to replace it.
This was noticeable on regular clipboard operations in quartz
Cherry-picked from 7ffcd85.
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
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>
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.
(cherry picked from commit bbe3554fa9)
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
(cherry picked from commit 159cccfe7b)
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
(cherry picked from commit 1ee36713fe)
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
(cherry picked from commit 280d606cd4)
window_type_hint_to_level(): applied patch from Paul Davis which moves
dialogs to NSFloatingWindowLevel. This is not quite the perfect
solution, but it's a pragmatic fix that makes apps which have both
window types much more usable, and prevents dialog from disappearing
under an application's main window.
(cherry picked from commit 59d49e1566)
With recent changes in attach semantics, we always need to attach before
committing. Without this changes to the window contents to not get reflected
in the content of the surface.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
Cherry picked to fix: https://bugzilla.gnome.org/show_bug.cgi?id=701341
