When we initialize OpenGL, check whether we have OpenGL 2.0 or later; if not,
check whether we have the 'GL_ARB_shader_objects' extension, since we must be
able to support shaders if using OpenGL for GTK.
If we don't support shaders, as some Windows graphics drivers do not support
OpenGL adequately, notably older Intel drivers, reject and destroy the GL
context that we created, and so fallback to the Cairo GSK renderer, so that
things continue to run, albeit with an expected warning message that the GL
context cannot be realized.
Also, when we could not make the created dummy WGL context current during
initialization, make sure that we destroy the dummy WGL context as well.
Fixes issue #4165.
Same thing as the previous popovermenu commit, except for the base popover
because the popovermenu needs special behaviour with e.g. sides arrow so
we need to have the "cycle around" for regular popovers here too.
Currently when moving the focus with (Shift+)Tab, it also traverses the window's
widgets, although it would be expected that the focus stays within the popover,
as it's (almost) like it's a separate window. This would be consistent with
the behaviour of the Up/down arrows, which do cycle around the focus once it
reaches the end.
So this commit makes the popovermenu cycle around focus in any direction, apart
from left/right because they are used to open and close submenus and it wouldn't
make sense anyway to cycle horizontally as there's usually only one widget per
line.
Long time ago, Cairo shadows in both GTK3 and 4 were drawn at a size about
twice their radius. Eventually this was fixed but the shadow extents are
still calculated for the previous size and appear unreasonably large: for
example, 141px for a 50px radius shadow. This can get very noticeable in
places such as invisible window frame which gets included into screenshots.
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3419 just divides the
radius by 2 when drawing a shadow with Cairo, do the same when calculating
extents.
See https://gitlab.gnome.org/GNOME/gtk/-/issues/3841
Our compose table format is still limited to 16bit
values for keysyms, but what we see in key events
can be 32bit values, and we treat them as such now.
Fixes: #4149
It broke keyboard focusing any widget added through the custom widget
menu feature. So for example if you put e.g. a custom check box widget
in a menu, you won't be able to focus it.
This is because the gizmo is mostly used to custom drawing with e.g.
CSS for small visual elements like scale markers. That's probably why
gizmo's default focus overrides block the focus from going through
the children. So this commit fixes it by overriding those and passing
the focus through the children.
Slide animations cause changes in the size requests due to the
behavior of GtkRevealer. We can avoid those by using cross-fades, which
don't have that problem.
Besides, cross-fades look better anyway.
