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.
The condition we check for to catch X servers going away
may not be accurate anymore, and the warning shows up in
logs, causing customers to be concerned. So, be quiet by
default, unless the user explicitly asked for a message.
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
When we clean up the uniform allocations after a frame,
it can happen that our space requirements actually increase,
due to padding that depends on the order of allocations.
Instead of asserting that it doesn't happen, just make
it work by growing our allocation.
Fixes: #3853
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.
gsk_rounded_rect_contains_rect was calling
gsk_rounded_rect_contains_point, which potentially
checks all four corners, for a total of up to 16
corner/point checks. But there is no need to do
more than 4 such checks to answer the question.
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.
At times (most often when closing subsurfaces that are scheduling
relayouts) the PHASE_PAINT handling gets broken with the following
sequence:
1. Surface receives wl_callback.done for the previous frame.
Surface is thawed.
2. A new update on the surface is scheduled. PHASE_PAINT is
requested directly on the frame clock. priv->pending_phase is
left unset in the surface.
3. Surface gets frozen
4. Frame clock processes the update scheduled at 2. The surface
is frozen, so paint is prevented. PHASE_PAINT is considered
handled.
5. Compositor emits wl_callback.done again. Surface is thawed.
6. At this point the machinery is off
- The surface didn't paint but has pending update regions
- priv->draw_needed is set in the toplevel and other portions
of the widget tree
- So queueing redraws is ineffective at eventually calling
gdk_surface_schedule_update() again on the toplevel surface.
- We don't paint anymore, so this broken state is not flushed
until other subsurface changes manage to schedule the missing
update.
To fix this, always set PHASE_PAINT in priv->pending_phase when
doing gdk_surface_schedule_update(). If the frame clock turns
around before the surface is thawed, it will still be waiting to
be processed the next iteration.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3750
When we don't get stettings from the portal, the current
fallback is 'awful fonts'. There is no need for that. Instead,
set the fallback values to grayscale antialiasing with slight
hinting.
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.
Instead of rendering the unclipped child to a texture
(and risking blowing the texture size limit, and bad
downscaling), just render the clipped region, and live
with the fact that we can't cache the rendered texture.
This avoid bad artifacts when scrolling long textviews
in rounded clips.
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
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
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.
