Don't rely on priv->resize_grip_visible as the code comment in the
variable declaration indicates.
This fixes warnings with GtkPlug, which can cause resize_grip_visible to
be TRUE but grid_window to be NULL - running tests/teststatusicon
reproduces this.
This broke with 7ef113ce56
With gtk-auto-mnemonics on, we hide mnemonics on focus out. We should also
check if the modifier is pressed on focus in and if so, show mnemonics again.
https://bugzilla.gnome.org/show_bug.cgi?id=618815
See the code comments for the reasoning behind this. After we don't
force a "guessed" minimum size for labels anymore, a lot of issues
started to surface that this patch attempts to fix. In particular:
1) Tooltips where wrapped as much as possible.
2) The recentchooser submenu displayed only ellipsize dots.
When called on a hidden window, gtk_window_present_with_time() would
just fall back to gtk_widget_show(), completely ignoring the passed-in
timestamp. This ended up working anyway if the timestamp came from
in-process, since gdk_window_x11_show() would initialize its user_time
from the time of the most recent event. But if the timestamp came from
another process, this would result in the window being shown with an
out-of-date timestamp.
Fix this by remembering the timestamp from
gtk_window_present_with_time(), and then setting the GdkWindow's
user_time from that when it the window is realized.
https://bugzilla.gnome.org/show_bug.cgi?id=647275
gtk_settings_get_default() was used to monitor the
"gtk-application-prefers-dark-theme" setting, rather
than the GtkSettings object associated with the window's
screen.
The metacity theme format allows to use colors from the current
GTK+ theme in window decorations. Since GTK+ now gained support
for dark theme variants, window managers using that theme format
(metacity, mutter, compiz via gtk-window-decorator) should be able
to use colors from the correct variant; so in case a variant is
requested, export it in the _GTK_THEME_VARIANT property on
toplevel windows.
https://bugzilla.gnome.org/show_bug.cgi?id=645354
This change does not introduce any functionality change, mostly
cosmtic cleanups, like re-linebreak when introduced annotations messed
up indentation or whitespace errors fixes.
Now GtkWindow takes some measures when setting toplevelness:
- When a window becomes toplevel after being embedded it saves
the visibility state and reshow's itself so that the window
re-realizes and presents itself again automatically
- When emitting hierarchy-changed, synthetically mark the toplevel
as not anchored, this allows the hierarchy changed propagation to
recurse properly.
GtkWidget also takes care to unset the parent window *after* unparenting
the widget and after emitting the heirarhcy changed that leaves a NULL
toplevel.
That means there are now 2 cycles of "hierarchy-changed" when removing
an embedded toplevel from a parent, first one that makes the new toplevel
a NULL one (since the toplevel flag is not yet restored), the second cycle
makes the removed window toplevel again when setting the parent window
to NULL.
GtkFileChooserDefault watches the toplevel and montitors "set-focus"
signal on it... however the connection needs to be remade when the
GtkFileChooserDialog is in an embedded toplevel.
Measure's taken: GtkWindow propagates hierarchy changes when
_gtk_window_set_is_toplevel() is called, gtk_widget_unparent()
unsets the widget's parent window earlier in the function so that
the possible hierarchy change is still able to properly access the hierarchy.
GtkFileChooserDefault checks if the "new" toplevel is indeed
gtk_widget_is_toplevel() but not the old one, GtkRange has been
updated to use gtk_widget_is_toplevel() inside it's hierarhcy_changed
vfunc, other classes already do this properly.
