If widgets want to clip things, they now need to do it themselves.
By not taking care of clip, we avoid the need to track clip. And by not
tracking clip, we can avoid all unnecessary cache invalidations that we
were doing for render nodes whenever the clip changed.
And when you are scrolling, the clip changes *a lot*.
priv->button is a guint, but we assigned it to a local gint.
gtk/gtkmenushell.c:734:37: warning: comparison between signed and
unsigned integer expressions [-Wsign-compare]
if (button && (new_button != button) && priv->parent_menu_shell)
^
...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
GTK does use libintl directly (in gtkmain.c, for example) and thus
needs to be linked to it (if found and/or needed).
Previously we most likely were getting libintl from glib, but
that stopped for some reason. Either way, explicit linking is
the right thing to do here.
Instead of going through an ancillary script to strip away the
`WL_EXPORT` annotation from the generated code, we should bump up the
required version of Wayland, and use the `private-code` argument for
wayland-scanner, which does the right thing for us.
Instead of connecting to / disconnecting from the frame clock, do it
inside the vfuncs next to changing the priv->realized boolean.
This removes a race between those 2 cases that could cause child
widgets' unrealize handlers to reconnect this widget to the frame clock
because it was still marked as realize when the widget had already
disconnected from the frame clock.
Fixes#168
But in turn, also allow it to work on widgets with their own surface.
This way, we can chain up from everywhere and won't have to export
gtk_widget_set_realized().
Now that queue_draw() isn't restricted to clip anymore, we don't need to
care about clip in the CSS engine either.
We do keep GTK_CSS_AFFECTS_CLIP around though because GtkWindow does
care for the window's size.
Even widgets with an empty allocation may still want to draw stuff.
Examples include shadows or child widgets with negative margins.
Fixes GtkEntry's progressbar not showing up anymore.
Deferring a bit further making those a standalone controller, make
binding activation happen on run_controllers(), so it happens by
default on widgets (unless the key event was consumed earlier)
without the need of a legacy event controller.
Non gesture controllers have no means to collaborate with other
controllers, thus should be considered standalone entities. It makes
no sense to propagate any further if scroll/key controllers handled
the event.
This is a GtkGesture done to deal with stylus events from drawing tablets.
Those have a special number of characteristics that extend a regular
pointer, so it makes sense to wrap that.
This may result on the later emission of crossing events, with one of the
sides being already unmapped/unrealized. The widget being unmapped will
result on repick and emission of a set of crossing events anyway.
This event controller is meant to replace usage from key-press/release-event
handlers all through. Optionally it can be set a GtkIMContext, so interaction
is carried by the controller.
1. Pass clip rectangles to gtk_snapshot_push_state() that point into
the state array.
2. g_array_set_size(len+1) the state array
3. Make that function realloc() the state array.
4. The clip rectangle now points into invalid memory
5. Use the clip array
This patch fixes things by moving step 5 to before step 2.
1b9aa1b708 ('a11y: drop the focus tracker') removed a bit too much. We
still have to emit window:activate/deactivate events. They are easy to
emit anyway.
Fixes#127
Overlays are drawings that get rendered on top of the inspected window.
The only overlay in existence so far is the highlight overlay, which is
used to highlight widgets and replaces the "draw" signal handler used
previously.
Instead of just notifying the inspector of what is going to be rendered,
allow the inspector to modify it.
This way, the inspector can overlay information it deems relevant over
the render node while still having access to what the actual widget
(without the inspector) would paint.
If you want to draw a widget to cairo today, you create a widget
paintable, snapshot it to a render node and then draw the render node to
cairo.
And yes, this is that complicated on purpose. Don't draw widgets to
Cairo.
This allows being more specific about the size.
It's useful in particular when the resulting render nodes might be
too small for the size, not only when they are too large. For the
latter case, using a clip node would be enough.
It also requires adding a clip node when rendering the resulting
paintable, but that should be optimized out by GtkSnapshot when not
necessary.
This is actually not just a mechnaism to protect against too many
signals, but it's also a method to getting those signals at the wrong
time.
For every size/content change, a widget needs to invalidate twice:
Once when it queues a resize/redraw (going valid => invalid) and once
when the new size/content is actually assigned (going invalid => valid).
However, one of those invalidations might be inconvenient for the
listener. GtkImage for example does not like receiving
invalidate-contents signals when new contents are assigned, but is fine
with them when the old ones go invalid. And it will not try to draw the
paintable in between anyway.
So by bypassing the 2nd emission if nothing was changed, we can make
GtkImage happy.
When the clip changes that is passed to a snapshot function, we need to
create eventual cached render nodes because they might not have drawn
their whole area before.
Fixes issues with redrawing when scrolling.
Instead of calling gdk_surface_invalidate_region(), just
gdk_surface_queue_expose() and rely on the renderer computing the diff
from the previous rendering.
It doesn't need to be exported anymore.
As a side effect, the inspector no longer has any information about the
render region, so remove the code that was taking care of that.
Now that we don't clip the created render nodes anymore, we don't have
to compute the clip region beforehand.
So snapshot the render nodes before initializing the renderer.
This requires a bunch of refactorings:
1. Don't pass the current clip region to gtk_widget_snapshot()
so we don't create full widget contents
3. Have a widget->priv->draw_needed that we invalidate on every
queue_draw() call and set on every snapshot()
2. In queue_draw(), walk the widget chain to invalidate the
render nodes of all parents
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.
(cherry picked from commit fa6994d033)
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.
(cherry picked from commit 209f908a03)
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
