Remove a boatload of "or %NULL" from nullable parameters
and return values. gi-docgen generates suitable text from
the annotation that we don't need to duplicate.
This adds a few missing nullable annotations too.
We iterate here from the target widget up the toplevel checking
for the previous and new grab, there's however 2 bugs here:
- The check for is_shadowed was different to the check for was_shadowed
- The loop started with the assumption that the widgets did not hold
a grab, just to change it if the grab widget was found. (or maybe
it's the other way around? it's unclear with the differing checks
for past/present state).
Make these checks consistent, and ensure we start with the right
assumption for the past/present grabbing state, and accounting that
new/old grab widgets may or may not be part of the pick stack.
With gtk_grab_notify_foreach() just taking care of emitting crossing
notifications due to the GTK grab change, rename it to a more apt
gtk_synthesize_grab_crossing().
The _gtk_widget_grab_notify() function just (maybe) did a) reset
controllers and b) hide toplevels. The second part was a testing
remnant introduced in commit 024d832d94, not part of the original
fix.
Do the former more concisely, called from the place where we figure
out whether a widget's ability to receive events changed due to
GTK grabs. It's across those changes that we are interested in
resetting the controllers.
With the gestures being reset both ways, GtkWindowHandle (and
probably other) gestures are now able to reset after a GTK grab
takes input away (e.g. GtkMenuButton). This could be seen as
a sudden jump the next time they'd be dragged with the mouse,
as the gesture would "resume" the previous interaction.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3942
When a new sequence is added to a GtkGesture, its state is looked
in other gestures in the same group, and made to match in this
gesture. This however happened a bit too early, before the
gesture touchpoint was fully set up. As this may result in signal
emission and whatnot, it's a good idea to make it happen with a
fully set up touchpoint.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3946
Match GtkListBox, so it's possible to use the same styles for them.
Update GtkListView and GtkGridView docs to reflect that, fix a few gtk-doc
formatting leftovers along the way.
The indentation of new lines inside documentation blurbs must be smaller
than 4 spaces, otherwise the Markdown parser will consider the line to
be part of a pre-formatted code block.
Fixes: #3945
When configuring the inspector display, preserve
debug flags that affect which GL variant we pick.
Otherwise, we may end up with a GLX context on the
default display, and an EGL context on the inspector
one. This hopelessly confuses libepoxy, and things
don't go well when that happens.
When loading the emoji data we just try to get the data for a language
while there may be territory specializations and emojibase provides
them.
So, split the loading function and try to load the data for the fully
defined language string (i.e. `it-ch`) before loading the generic one
for the language (i.e. `it`) and eventually falling back to the generic
english.
The change in 875a92b95f made labels strip
out underlines earlier, but overlooked that this made
mnemonics not work before the timeout to show them
has passed. That was unintentional. Make mnemonics
work regardless of their visibility, again.
When a drop causes the event controller to be finalized
(directly or indirectly), we end up segfaulting while
trying to wrap up the drag operation. So, keep a reference
on the GtkDragSource from when the drag begins to when
it is done.
This fixes a crash in gnome-todo when dragging tasks.
Avoid a nested listbox, show the connector,
don't show information we don't have. Also,
disconnect all signal handlers from the display
when the inspector is going away.
This fixes nautilus crash and perhaps other callers issues.
Nautilus (and sometimes glib) crashes with malformed URI inside of the
bookmarks file .config/gtk-3.0/bookmarks when it has no LABEL.
This is result from the closed glib MR #2065 analysis and agreement.
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2065#note_1091979
Signed-off-by: Geyslan G. Bem <geyslan@gmail.com>
Just from reading the code, it seems that we
should unset .csd and .solid-csd at the same
time, since the are mutually exclusive and
we unset them here so realize() can set one
of them again.
The code in gtkwindow.c for dealing with the various
combinations of client-side decorations and client-side
shadows is entirely too complicated.
This commit does not really clean it up, but simplifies
one of the shadow conditions far enough to make some
sense.
With this change, I get the expected decorations in
all the cases I can easily reproduce locally.
Deriving the resize border size from the shadows
carries the risk that we might end up with uneven
resize borders (or none at all, on some sides).
So, justs enforce that we have a big enough shadow
width on all sides.
Previously it was impossible to compose characters on higher levels of
some keyboard layouts as pressing the level selection key would just
exit compose mode.
Examples for affected keyboard layouts include the Latvian
apostrophe-variant "lv(apostrophe)" (latched third level), the extended
German keyboard layout "de(e1)" (latched fifth level) as well as the
multilingual Canadian keyboard layout "ca(multix)" and the German
neo-layout "de(neo)" and its descendants (shifted fifth level).
To reproduce, set a compose key and select the Latvian apostrophe layout.
Notice that you now can input [ by pressing first the ' and then the 8-key.
Then pressing <compose>'8'8 should produce ⟦, but prior to this patch it
did not.
The invisible resize borders have been wider than they
should, for a while. Go back to a size close to what
we have in GTK3.
To summarize: resize borders will be at most 12 pixels
on each size, but never wider than the windows shadow.
The resize corners have 'legs' of 24 pixels where you
still get a corner resize cursor.
Fixes: #3856
Only send selection-changed events when we either
had a non-empty selection before, or have one now.
This should help orca speak the right things, and
not the wrong things.
Related: #3549
Orca relies on these to keep track of the focus location,
ignoring the focused state. With this change, orca can
once again speak text in entries as I type.
We are starting with a pretty empty a11y object tree,
and we want orca to bring more of it into existence
by navigating the tree. But that only happens when we
send it events. Primarily focus events, which come in
from GTK via the platform_change mechanism. So realize
the context when we are sending platform_changes,
otherwise, orca never gets the mesage.
With most context realization happening inside
GtkAtspiContext in response to D-Bus calls, the
code in gtk_widget_realize_at_context that sets
the role is not executed for most accessibles,
causing them to be stuck with the 'filler' role
that makes orca ignore them.
To fix this, split gtk_widget_realize_at_context
into the actual context realization (getting on
the bus) and the setting of widget-specific
properties, and do the latter part when the
widget is rooted.
This makes accerciser report proper roles for
entries and buttons. Orca still has an issue
with getting the hierarchy populated.
Orca ignores events unless the object is inside an object
with role window and states ACTIVE and SHOWING. To arrange
for this, introduce a new ACTIVE platform state, and set it
for windows when they are active.
This gets orca to be a lot more talkative.
Linux 3.4 added support for the MADV_DONTDUMP option to madvise(), which
requests that the covered memory not be included in coredumps. It makes
sense to use this to prevent cases where application crashes could
result in secrets being persisted to disk or included in dumps that are
uploaded to remote servers for analysis. I've avoided making this fatal
since there's a chance this code could be built on systems that have
MADV_DONTDUMP but run on systems that don't.
This cleans up and moves the code to load files
while taking the scale into account. Along the way,
we drop the last uses of GdkPixbufAnimation, and
consolidate the pixbuf using code in one place.
In commit 4a76abffd4, we deferred unsetting focus
and default until after the next draw, overlooking the
case where the focus is set to another widget before we
ever get to the unsetting.
Fixes: #3413
Avoid passing through random key press or release
events while we are showing preedit. That prevents
'accidents' like typing Ctrl-. bringing up the
Emoji chooser during preedit, or hitting Ctrl-a
after the Compose key moving the 'dot' around in
vim in terminals.
Not for symbolic icons.
Don't apply `-gtk-icon-filter: opacity(0.5);` to the symbolic icons as
they already have the "gray" colors indicating the disabled state.
Symbolic icons can be styled using the `color` property.
Also remove the obsolete comment.
Some locations have to be mounted, but their mounts are not user-visible
(e.g. smb-browse). Though this is maybe a bit weird, it is how it works
for years. The problem is that the commit 267ea755, which tries to get the
default location for opening, caused regression as it doesn't expect such
possibility. Before this commit, such locations were opened without any
issue, but nothing happens currently after clicking to "Connect" except of
clearing the "Connect to Server" entry. Let's fallback to the original
location if the mount was not found to fix this regression.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1811
Propagate the focus-on-click setting to the button
inside, so that setting menubuttons as !focus-on-click
works as expected. This helps for menubuttons in
header bars, where dragging on the button will otherwise
steal focus from the content.
Commit 3dbf5038fa tried to defer focus changes
until after rendering is done. But it failed to do so, since
the toplevel ::render handler is still before rendering of
popups that are attached to that toplevel. To do this
properly, we need to do it in the AFTER_PAINT frame clock
phase.
Fixes: #3725
We used to override cursor to use all-scroll while the
content is being scrolled. Unfortunately, there is several
problems with this:
- It is really only expected certain devices, and we don't
have the device information on Wayland
- With the way cursor setting works in GTK4, non-NULL cursors
of the content (eg the text views ibeam) win, making the
scroll cursor not show up
- Under X11, we seem to miss scroll end events and then
the scroll cursor gets stuck
Therefore, just remove this feature.
We need to invalidate the style when font-size changes,
because we propagate this value through the initial
value of the CSS font-size property, and it will not
be recomputed otherwise.
Forgetting to do so was causing the Wayland im context
to leave behind a dead event controller. This was showing
up as a crash when closing the inspector after changing
the im-module property of a GtkText widget. The crash
was delayed until closing the inspector because the
inspector keeps a ref on the event controllers of the
currently shown widget.
The use of the keyboard-activating CSS class for buttons was added
in [1], but the style did not apply to buttons with has-frame=FALSE.
[1] 00923615f4 ("button: Add back visual feedback for keynav", 2021-04-01)
The change in 740559a54f to populate the list incrementally
broke initial font selection. Fix that, by trying to select
until the incremental filling is done.
Fixes: #3687
Since we are likely going to see theme names like
Adwaita and HighContrast, make fallback work as follows:
Adwaita -> Default
Adwaita:dark -> Default:dark
HighContrast -> Default:hc
HighContrast:dark -> Default:hc-dark
HighContrastInverse -> Default:hc-dark
Other themes will fall back to Default, as before.
We lost the visual feedback for activating a button
via Space or Enter when the :active pseudo-state became
managed. Bring it back with a style class.
Fixes: #3813
This was breaking muscle memory of people with
the us intl keyboard layout, for important keys
such as '. The unfortunate side-effect is that
our handling of <dead_acute> is a bit hampered
by sequences that don't fit the pattern. But
such is life.
Fixes: #3807
Rename the included theme to Default, with 4 variants:
light, dark, hc, hc-dark. This replaces Adwaita,
Adwaita:dark, HighContrast and HighContrastInverse.
We still make the themes available under these names,
and we still set up Adwaita-dark and HighContrastInverse
as the dark variants of Adwaita and HighContrast.
The unification of the theme variants under Default
is not quite perfect; it would be nice to merge
the assets/ and assets-hc/ subdirectories and render
all assets from a single svg file.
If we scroll down in a list that's still being filled, we hit the edge and
initiate overshoot, and then the adjustment's upper value increases. This
leads to an unwanted bounce back.
Additionally, if in a similar situation the upper value decreases, the
overscroll glow gets stuck.
Update kinetic scrolling upper and lower value on changes, and immediately
cancel it if dimensions on that side change.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3752
Instead of getting current display before calling settings signal removal,
do it inside remove function and only if there is a signal connection to remove.
