gtk_window_get/set_attached_to() is a new API that allows for windows to
be attached to a GtkWidget.
The attachment is a logical binding between the toplevel window and the
widget that generated it; this kind of information is currently used to
propagate style information from the widget to the window, but is also
useful e.g. for accessibility.
https://bugzilla.gnome.org/show_bug.cgi?id=666103
'window-unfocused' is too long and mentions "focus" which is historically
loaded with the meaning "input focus".
'backdrop' isn't generally used in GUI speak and still conveys the state the
widgets in an unfocused or background toplevel window are in.
This also removes setting the FOCUSED state flag when
gtk_window_has_toplevel_focus() since this effect can now be done with the new
WINDOW_UNFOCUSED flag instead which actually works better regarding X grabs
and modal windows.
For maximized windows, titlebars cannot be used to reposition or
scale the window, so if an application does not use it to convey
useful information (other than the application name), the screen
space occupied by titlebars could be put to better use.
Add a new window property which requests from the window manager
to hide titlebars when windows are maximized to account for this.
https://bugzilla.gnome.org/show_bug.cgi?id=665616
Instead of painting the window background on the grip_window we now
only paint it on the GtkWindow->window, and we make the grip_window
have a transparent background.
We can't really make transparent window handle background optional
via css atm, because the handle color is actually based on the
background color, so if that is set to transparent we won't draw
anything.
gdk_cairo_region_create_from_surface doesn't work correctly on PPC.
This is most prominently seen with the GTK window resize grip, the
shape of which is mirrored every eight pixels horizontally.
At the same time, use an A1 surface for the resize grip shape to
eliminates an A8->A1 surface conversion.
We have an event, so the correct thing to do is to pass
the device into the function that we are calling. GDK
just grew a variant that takes a device, for this purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=663444
This commit introduces a new setting, gtk-visible-focus, backed
by the Gtk/VisibleFocus X setting. Its three values control how
focus rectangles are displayed.
'always' is equivalent to the traditional GTK+ behaviour of always
rendering focus rectangles.
'never' does what it says, and is intended for keyboardless
situations, e.g. tablets.
'automatic' hides focus rectangles initially, until the user
interacts with the keyboard, at which point focus rectangles
become visible.
https://bugzilla.gnome.org/show_bug.cgi?id=649567
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
