This fixes a long standing bug in pid_get_parent on OpenBSD (which was mine
so... my fault). kp wasn't properly allocated and the function could return
random failures.
The key controller was consuming key events
for modifier keys, for no entirely convincing
reason, which leads to problems when somebody
actually listens for those, such as the simple
input method does for C-S-u processing.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1884
There are two ways GTK can add a headerbar to a dialog:
- the dialog is constructed with the :use-header-bar property
- all windows should use client-side decorations
In the first case, the headerbar is added by GtkDialog with no
dedicated style class, and in the latter by GtkWindow with the
"default-decoration" style.
As a result, dialogs with plain titlebars can end up with clearly
distinct and inconsistent styles.
To address this, allow headerbars to track whether they should use
the "default-decoration" style and enable it for dialogs.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/836
We don't want to return a GFile because GFile can't handle can't deal
with data: urls.
That makes the code a bit more complicated that doesn't deal with those
URLs, but it makes the other code actually work.
GtkCssImageUrl also now decodes data urls immediately instead of only at
the first load. So don't use data urls if you care about performance.
When we're at the end of a block and gtk_css_parser_get_token() returns
NULL, gtk_css_parser_commit_token() still consumed the next token.
It does not anymore.
This does not affect the CSS parser, but it exposes issues with the
render parser, which previously just consumed too many closing } tokens
in the past.
The calls used old bugzilla URLs and nobody cared about that.
So apparently they are very unused.
There's also a potential conflict between gitlab and bugzilla URLs and
what base bug to use there.
The old usages have been converted to comments.
When looking for versioned theme files, we were
looking for directories names gtk-4.x for x
bigger than 14, which mades sense for GTK 3,
but we are starting out at 0 again, so remove
this check.
The inspector, and other tools introspecting the widget structure like
gtk-builder-tool and Glade, may very well want to access the default
layout manager used by a class, especially if there are layout
properties involved, without having a whitelist of widget/layout manager
associations.
Some widgets have a well-defined layout manager created alongside their
own instance; if they do, we can handle the layout manager creation at
the GtkWidget instantiation.
The default value of GtkWidget::visible changed
from FALSE to TRUE from GTK 3 to 4. Make --3to4
deal with this by ensuring the visible property
is explicitly set, before simplifying.
