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
This is meant as an input to the font chooser.
We don't want the user to select a language, but
rather have fonts presented as they would work for
the current language. Therefore, do away with the
lang/script combo on the tweak page.
Really exclude the portions in the gtkfontchooserwidget.c that are built
when HarfBuzz and PangoFT2 are built, and update the Meson files to
exclude such sources as well from the main GTK SO/DLL and from the
gtk4-demo program.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Remove g_auto*() usage from these sources and use the traditional
g_free(), as g_auto*() are GCCisms (or CLangisms).
Also, don't include unistd.h unconditionally and stop including
langinfo.h and dirent.h, since they seem to be unused.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
For some font features, we can figure out affected
glyphs, and show before/after. For some others, we
hardcode typical sequences.
Still to do: figure out how to find ligatures and
show them.
If GtkExpander:sensitive was FALSE, the arrow still got the normal fg
colour, which made it look clickable, in contrast to the adjacent label.
Fix this by adding selectors to catch the applicable :disabled states.
Note: Needing these may indicate an oops in generic styles elsewhere,
but I couldn’t see any, so let’s just get it looking right for now.
Close https://gitlab.gnome.org/GNOME/gtk/issues/146
Add a new W32 backend-specific message filtering mechanism.
Works roughly the same way old event filtering did, but without
events (events are GDK/X11 concept that never really made sense
on W32), so there's no functionality for 'altering' events being
emitted. If an event needs to be emitted in response to a message
do it yourself.
Implemented like this, it should give better performance than
if we were to use GLib signals for this, since W32 sends a LOT
of messages (unlike X11, which doesn't send events as often)
all the time, and invoking the signal machinery on *each* message
would probably be bad.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
This makes the code compile again, though obviously there have been
some substantial changes in how IM contexts work, so it's possible
that IME IM context doesn't work now.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Check for freetype2 version, because pangoft works with any version
(pangoft availability does not indicate that ft2 is new enough), unlike
GTK.
On Windows, since pangoft is optional, we check for the presence of
freetype2 .pc file first after finding that we have pangoft, and then
check for FT_Get_Var_Design_Coordinates() manually by looking for the
freetype headers and .lib first, and then looking for the presence of
that symbol, since freetype2's Visual Studio build system does not
generate a .pc file for us.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Turn the GtkFontChooserLevel field into flags, and
add flags for OpenType variations and features. The
motivation for this is to make font-features in the UI
opt-in, since applications need to support them by
applying the pango attribute.
Instead of fiddling around with scale in the iconhelper (and getting it
wrong), create a GtkScaler around the paintable that takes care of the
scaling.
This is the equivalent snapshot function to pango_cairo_show_layout().
Not to be confused with gtk_snapshot_render_layout(), which is the
equivalent to gtk_render_layout().
This is a special case of the transform node that does a 2D translation.
The implementation in the Vulkan and GL renderers is crude and just does
the same as the transform node.
Nothing uses that node yet.
When drawing onto a recording surface, source surfaces get cached.
But if we g_free() the surface data after we're done, that cache is
gonna point at invalid data...
