When a non-existing file is selected in the file chooser
for print-to-file, we weren't updating the button label
to show the new filename. Fix that.
Also, use newer file chooser api.
This is a hot path when scrolling a ColumnView, and
g_param_spec_pool_lookup () was taking a measurable part in this hot
path. Instead, notify using pspecs to avoid the name lookup.
Related: https://gitlab.gnome.org/GNOME/gtk/-/issues/3334
freeze/thaw_notify () showed up on the perf trace for rapid ColumnView
scrolling. Track the three properties manually to make it a little
faster.
Related: https://gitlab.gnome.org/GNOME/gtk/-/issues/3334
This looks like a leftover excess invalidation from when the surrounding
code was refactored to not just be called on parent changes but also
when repositioning inside the same parent in commit
507016cafc
Ivan Molodetskikh found this problem in
https://gitlab.gnome.org/GNOME/gtk/-/issues/3334#note_1445873 which
contains a longer analysis of this problem and the performance
reductions it causes.
Related: #3334
This allows consumers greater control over the label without the need
to expose each of the label properties as part of GtkCheckButton interface.
Specifically, motivation for this commit is to be able to wrap the label.
Closes#4698
The fixed-size format we use currently can only handle up
to 32768 bytes of string data. If a compose file contains
more, reject it with a warning.
Fixes: #4873
Even if the FileChooserNative instance drops out on us while we're still
waiting for the portal to answer, we should keep the data and pointers
alive until the sequence of asynchronous operations is running. The code
already tries to do that, by acquiring a strong reference to the
GtkFileChooserNative instance, but it's also freeing data as soon as the
dialog is hidden, while asynchronous callbacks that will look at the
fields on that data are still in flight.
To avoid that, we defer freeing the data until the asynchronous
callbacks are invoked, and we keep a reference on the dialog while we're
emitting signals on it.
Fixes: #4883
The enum values are not compatible, and moreover, there is an extra
GTK_WRAP_NONE that PangoWrapMode doesn't have - thus,
pango_wrap_mode_to_string() will assert.
As far as I can tell, Orca does not read the wrap-mode key in the
dictionary for text attributes, anyway.
Fixes: #4869
if the loop for determining max width grows too big, print an error and
abort assuming that a satisfactory value was reached.
This will cause wrong layout and might cause widgets to overlap, but it
will not infloop.
It actually works around and doesn't really fix the primary cause of the
following bugs, but good enough to close them:
Fixes: #4252Fixes: #4517
If we get consecutive preedit string updates that announce a NULL
string, we still do end up issuing ::preedit-changed with those.
Ignore changes from NULL to NULL, it is the other combinations which
must issue this signal.
adwaita-icon-theme has more appropriate icons for showing/hiding text now.
use those, and in the process fix the fact GtkPasswordEntry has been using
them the other way around.
The root accessible object is registered asynchronously, as it needs to
call a method on the AT-SPI registry daemon. This means we need to defer
registering the GtkAtSpiContext on the accessibility bus and in the
cache until after the registration is complete.
Fixes: #4825
Direct access of the fields of the union trips compiler warnings with
GCC 12, such as:
../gtk/gtkimagedefinition.c:135:13: error: array subscript
‘GtkImageDefinition {aka union _GtkImageDefinition}[0]’ is partly
outside array bounds of ‘GtkImageDefinitionEmpty[1]’ {aka
‘struct _GtkImageDefinitionEmpty[1]’} [-Werror=array-bounds]
When changing folders, we were making the select
button insensitive when there is no folder selected.
However, the select button should be usable to
select the current folder.
Fixes#4020
It is very irritating when the entry completion popup
appears not in response to user input in the entry.
In particular, when that happens right as the dialog
is shown.
To prevent that, temporarily disable completion
when setting the entry text programmatically.
When changing folders, we were making the select
button insensitive when there's no files around.
That doesn't make sense in save mode when we don't
want to select a file but create one.
Fixes: #4851
This allows the user to navigate via tab the links in a label and exits
the widget after the last link, when moving forward, and first link,
when moving backward.
This also ensures that ellipsised links arn't focused.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4681
The `has-tooltip` property gets set to `false` for label with links if no
link is selected. This makes sure to only change the property to `true`
but never to `false`.
Instead of populating the properties right away (when the widget might
not have been allocated yet, and hence cannot know the right values),
the widget should queue an allocation, where it will populate the
values.
For reasons that only apply to the old serial handling, asking for
the surrounding after IM changes resulted in lazy handling of
commit() afterwards.
With the recent interpretation of serials, this problem became more
apparent, since it is in fact very likely that the last interaction
step after an IM change is notifying of the changed surrounding
text after the IM change was applied.
Make handling of surrounding text similar to caret position changes,
always commit() after the state change, but skip through non-changes.
This makes the compositor state fully up-to-date after an IM change.
The gesture as connected currently on the child GtkText is easily overridden
by the parent editables (and gently done so in the attempt to consume all
clicks).
Connect this gesture to the parent editable widget in these cases, so the
gesture can cohabit with the click-consuming one. It's not part of the same
group, but it won't be abruptly cancelled.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4795
Currently the GtkIMMultiContext may stick to a delegate GtkIMContext
that no longer applies after the multicontext is dissociated from
any widget.
Handle set_client_widget() so that it can handle changes between
widgets from 2 different display, but also so the delegate is made
NULL whenever the context has a NULL widget.
Doing so, any new client widget results in a new delegate IM context
lookup from the right GdkDisplay and GtkSettings, which avoids any
mix up.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4805
We may well be using an EGL context that does not support Desktop (W)GL on
Windows, such as in the case of using libANGLE. So, check whether WGL is
supported for this running instance before trying to query WGL extensions.
This will get rid of warning messages from libepoxy.
Otherwise a stray scroll controller may prevent others from getting hold
events, even if it always propagates scroll events and does absolutely
nothing.
As documented:
> Overlay children whose alignments cause them to be positioned
> at an edge get the style classes “.left”, “.right”, “.top”,
> and/or “.bottom” according to their position.
Likely accidental regression in b7ee2cbc28
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/2099
If using the opacity CSS property the renderer cannot optimize these
handles without the use of offscreens due to the use of both a border
and rgb render node.
Instead, we can apply the alpha to the color values and get the same
effect in a way that the GL renderer can optimize without the use of
offscreen textures for a sizeable reduction in runtime overhead.
The pixel distance could be small enough between tick() calls that
this kind of checks might potentially become a problem. Rely only on
the calculated velocity to trigger the STOPPED phase, and use a lower
threshold to avoid cutting the animation too early.
Related: https://gitlab.gnome.org/GNOME/gtk/-/issues/4725
In order to properly accumulate scroll velocities, we need to keep
the kinetic scroll helpers after we have possibly stopped them
in the process of initiating a further scroll flick.
So, instead of stopping (and destroying) those helpers on scroll-begin,
keep them until the next scroll-end if a scroll was initiated before
kinetic scroll finished. This way we can fetch the last velocity when
calculating the extra kick.
In order to ensure the helpers don't live beyond what it is expected,
we now also remove them after a finished hold event.
Fixes the accumulation of scrolling velocity on consecutive scroll
sequences.
Do not depend on the kinetic scroll helpers existing or not before
exiting the animation, as we may want to keep those a little bit
longer after stopped.
We may want to fetch the last velocity obtained, even though we
preemptively called stop() on a kinetic scroll helper. Keep this
velocity so it can be queried later on.
On the "scroll" signal, the widget uses
gtk_event_controller_scroll_get_unit() to get the
scroll unit.
When the unit is GDK_SCROLL_UNIT_WHEEL, the
behavior is unchanged: the widget scrolls a
certain number of pixels at each wheel detent
click. This number of pixels is determined by the
window dimensions in get_wheel_detent_scroll_step().
When the delta unit is GDK_SCROLL_UNIT_SURFACE, the
widget directly adds the delta to the number of
scrolled pixels no matter the window dimensions.
We were missing the surface offset (e.g. shadows) at the time of expressing
the text caret location in surface coordinates. Add this offset so the
coordinates are as expected by the compositor.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4668
