Widgets that already have a resize queued don't need to walk the whole
parent chain and queue another resize. It's enough to do it once per
resize.
This also means that sizegroups cannot use the shortcut of just
invalidating the first widget in the group anymore. That widget might
already have a resize queued while others don't.
This happens way too much, so it's disabled unless GTK_DEBUG=geometry is
on.
Also, we can't detect it in the call to queue_resize() yet, only during
size_allocate(), so the warning comes after the signal emission.
... and API to set and unset it.
It is set when gtk_widget_queue_resize() is called.
It is unset when gtk_widget_get_preferred_width/height() is called.
So far it is not used.
Before this commit, a widget tree like this:
Window
AnyContainer (part of SizeGroup1)
GtkClutterEmbed
SomeWidget
when calling gtk_widget_queue_resize(SomeWidget), would invalidate
SizeGroup1, when it should have stopped at the GtkClutterEmbed (which is
a RESIZE_IMMEDIATE child).
This is so widgets can queue a rerun of their allocation logic, but
without triggering resizes everywhere.
For now, it just calls gtk_widget_queue_resize().
Ignore the geometry widget passed to gtk_window_set_geometry_hints().
Usind the widget itself was a hack that complicates the size request
machinery.
It is also incorrect in that it doesn't respect height-for-width.
Last but not least, it was only used by gnome-terminal and that
application can easily work without it.
And remove the API to set that variable.
If you want the entry to not fill its whole allocated area,
gtk_widget_set_valign (entry, GTK_ALIGN_FILL);
will give you the old behavior.
Passing GTK_ICON_LOOKUP_GENERIC_FALLBACK to the icon lookup doesn't work
for GIcons, so we have to make sure we use the right GThemedIcon.
Fixes image-icon-name-use-fallback reftest.
After figuring out what the actual problem is, name the reftest
properly.
The actual problem is that the use-fallback property is ignored when
using an icon-name on GtkImage.
Fallback seems to be working in the GtkIconTheme test suite, but fails
in GtkImage itself.
This is a test for a bug in the Bluetooth settings. An icon named
"phone-apple-iphone" should fallback to "phone" if the
gnome-icon-theme-extras package isn't installed.
If the shared context is in legacy mode, or if the creation of a core
profile context failed, we fall back to an EGL context in compatibility
mode.
Since we're relying on a fairly new EGL implementation for Wayland, we
don't fall back to the older EGL API, and instead we always require the
EGL_KHR_create_context extension.
https://bugzilla.gnome.org/show_bug.cgi?id=756142
If GLX has support for the GLX_ARB_create_context_profile extension,
then we use the GLX_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB; if it does
not, we fall back to the old glXCreateNewContext() API.
We use the shared GdkGLContext to decide whether the GLX context should
use the legacy bit or not.
https://bugzilla.gnome.org/show_bug.cgi?id=756142
If we're using modern GLSL, then we should stop using deprecated
modifiers, like 'varying' and 'attribute', as well as deprecated global
variables, like 'gl_FragColor'.
On the other hand, with legacy contexts we should be using older GLSL
shaders, to maximize compatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=756142
We want to have the ability to fall back to legacy GL contexts when
creating them. In order to do so, we need to store the legacy bit on the
GdkGLContext, as well as being able to query it.
Setting the legacy bit from outside GDK is not possible; we cannot
create GL contexts in 3.2 core profile *and* compatibility modes at the
same time, and if we allowed users to select the legacy mode themselves,
it would break the creation of the GdkWindow's paint GL context.
What we do allow is falling back to legacy GL context if the platform
does not support 3.2 core profiles — for instance, on older GPUs or
inside virtualized environments.
We are also going to use the legacy bit internally, to choose which GL
API we can use when drawing GL content.
https://bugzilla.gnome.org/show_bug.cgi?id=756142
If the last tag toggle is the end iter, the function returned the wrong
tag toggle.
This resulted in some bugs where the view wasn't relayout/redrawn
correctly.
The function also always returned TRUE, probably because the return
value is used nowhere. But for consistency with
_gtk_text_btree_get_iter_at_first_toggle(), it's better to keep the
return value, and also because otherwise the function would be wrong (it
doesn't always return a tag toggle, if there is none).
https://bugzilla.gnome.org/show_bug.cgi?id=755413
keyboard_handle_leave() might be called with a NULL surface resource
(for example if the surface was destroyed after the event was sent). If
so, we should still deal with the keyboard focus lost event, otherwise
we will both leak (the keyboard_focus GdkWindow reference) and miss
stopping the key repeat timer.
https://bugzilla.gnome.org/show_bug.cgi?id=755927
_gtk_accessibility_init() only gets called if the default
display changes, but in case gdk_init() is called before gtk_init()
the default display is already set and no property notification occurs.
This can happen quite easily in pygobject where
"from gi.repository import Gdk, Gtk"
will call gdk_init() followed by gtk_init() in the Python overrides.
This fixes it by checking for a default display in all cases.
Removing pages from the assistant with gtk_widget_destroy() used
to work. It broke with the recent interposition of a box between
each page and the notebook. Fix this by cleaning up when the box
child is removed.
https://bugzilla.gnome.org/show_bug.cgi?id=756042
In fact there were two issues:
1. GtkFlowBoxChild with "can-focus"==FALSE should pass the focus
to its child immediately.
2. GtkFlowBox with "can-focus"==FALSE should cease its custom keynav
implementation and fall back to the default GtkContainer behavior
which is more natural.
Thanks to these changes the flow box can act as a better replacement
for GtkGrid and similar containers.
https://bugzilla.gnome.org/show_bug.cgi?id=753371
