This will be used in subsequent commits to fix the sign by which the
value is changed in response to directional scroll or keypress events.
The idea is: you have a movement to make – in the form of a delta that
follows widget directions, i.e. −1 means left or up, +1 means right or
down – and you want to know whether that delta needs to be inverted in
order to produce the intuitively expected directional change of :value.
The existing should_invert() is not sufficient: it just determines
whether to invert visually, but we need more nuance than that for input.
To answer that – while not doubling up the work for scrolls and keys – I
add a helper should_invert_move(), which considers other relevant state:
• A parallel movement on priv->orientation should just use the existing
should_invert(), which already worked OK for this case (not others).
• Movements on the other orientation now depend on priv->orientation:
◦ For a horizontal Range, always invert, so up (i.e. −ve in terms of
widget coords) always means increase value & vice-versa. This was
done in get_wheel_delta(), but move it here for use with keys too.
◦ For a vertical Range, ignore :invert as it’s only relevant to the
parallel orientation. Do not care about text direction here either
as RTL locales do not invert number lines, Cartesian plots, etc.
This returns TRUE if the delta should be inverted before applying to the
value, and we can now use this function in both scroll and key handlers.
https://bugzilla.gnome.org/show_bug.cgi?id=407242https://bugzilla.gnome.org/show_bug.cgi?id=791802
.set_accel_path(): Use (nullable) instead of (allow-none), and explain
what a NULL means (albeit very briefly)
.set_title(): Annotate @title as (nullable), and explain NULL’s meaning
...from CellRenderer::start-editing, to point people in the direction of
info about the lifecycle of the Editable and how to do generic setup.
https://gitlab.gnome.org/GNOME/gtk/issues/154
Drop the line copied from .activate(), replace it with a description of
what this method actually does, and explain what a NULL result means.
https://gitlab.gnome.org/GNOME/gtk/issues/154
* Note in the intro that we're really thinking about temporary widgets
* Mention a gotcha regarding GtkEntry and how ::focus-out stops editing
* Give some examples of what you'd want to do in ::editing-done
* Be a bit more precise about what ::remove-widget represents
* Summarise the lifecycle between Renderer/Editable in .start_editing()
* Emphasise again there that this should be viewed as a temporary widget
https://gitlab.gnome.org/GNOME/gtk/issues/154
... and use it to not connect anything to the frameclock if it isn't
set.
This gets around the problem that the frame clock is disconnected before
GtkWidgetClass.unrealize() is called but the widget is still marked as
realized and the frame clock is available during the vfunc, which makes
calls like gtk_widget_queue_resize() reconnect to the frame clock.
Closes#168
The links to the repository's web UI still refer to the old
git.gnome.org cgit UI, and to the master branch; we should be using
GitLab and the gtk-3-22 branch instead.
When asked for a nonexistent (positive) monitor number,
gdk_x11_display_get_monitor would (at best) return an uninitialized pointer,
instead of returning NULL.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/107
Redrawing is insufficient: when :role changes to/from NORMAL, the
indicator gadget reallocates, but we didn't reflect that in the widget.
https://gitlab.gnome.org/GNOME/gtk/issues/163
When a project has a bundled copy of our macro included in tarball
source releases, typically in a m4/ or aclocal/ directory, aclocal
uses the serial number to determine whether the system copy in
/usr/share/aclocal is newer or older than the bundled copy. Without
a serial number, the bundled copy will always be used and will not
be overwritten, even if it is outdated.
Signed-off-by: Simon McVittie <smcv@debian.org>
delete_range_cb is set to be called before the text suppression done by
the gtktextlayout (otherwise it does not work properly). But at that
point the cursor position is not yet up to date. We thus need to move
the accessibility cursor notification to after the actual text
suppression, by using another callback.
This fixes cursor position in brltty screen reading.
The second parameter of the text-changed::delete event is to be the length,
not the end position. This fixes spurious text removals in brltty
screen reading.
The stable xdg_shell port (5c8bb51a) introduced an error in
gdk_wayland_window_set_geometry_hints which would set the minimum size
to the maximum size, if provided.
This resulted in various wxWidgets apps (FileZilla, Audacity, Veracrypt)
crashing because they attempted to allocate a ginormous surface.
Fixes#157.
Like other widgets, this returns a floating reference, so
(transfer full) is wrong. Just omit the annotation as others do,
thus implying (transfer none).
Close https://gitlab.gnome.org/GNOME/gtk/issues/156
