With gtkmm, when using `Application()`, the display is initialized
before we know the application name and therefore, the program class
associated to the display is NULL.
Instead of providing a default value, we set it equal to program name
when NULL. Moreover, we give up on capitalizing the class name to keep
the code super simple. Also, not using a capitalized name is
consistent with `gdk_x11_display_open()`. If someone has a good reason
to use a capitalized name, here is how to do it.
```c
class_hint = XAllocClassHint ();
class_hint->res_name = (char *) g_get_prgname ();
if (display_x11->program_class)
{
class_hint->res_class = (char *) g_strdup (display_x11->program_class);
}
else if (class_hint->res_name && class_hint->res_name[0])
{
class_hint->res_class = (char *) g_strdup (class_hint->res_name);
class_hint->res_class[0] = g_ascii_toupper (class_hint->res_class[0]);
}
XSetClassHint (xdisplay, impl->xid, class_hint);
g_free (class_hint->res_class);
XFree (class_hint);
```
Fix eff53c023a ("x11: set a default value for program_class")
It is basically not used by default and is pretty much broken at this point, so
it's about time to drop it.
Let's focus on fixing the OLE2 DnD protocol.
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.
