This used to be done before the gestures port, and was removed
accidentally, so keep the motion_notify_event handler just for
this, and fallback to having those events handled by gestures
too.
This gesture was only meant to react on GDK_BUTTON_PRIMARY (either
through real pointer events, or implicitly assumed from touch events),
as it used to behave before gestures. Otherwise the gtk_drag_begin*()
call assumes being triggered by button 1, and the drag misbehaves
because that button isn't really in the state mask.
https://bugzilla.gnome.org/show_bug.cgi?id=731016
Mainly doing s/TARGET/BUBBLE/ on the fully ported widgets, but GtkTreeView
where the double click handler has moved to GTK_PHASE_TARGET so it runs
parallelly to the still existing event handlers.
Event controllers now auto-attach, and the GtkCapturePhase only determines
when are events dispatched, but all controllers are managed by the widget wrt
grabs.
All callers have been updated.
Presses alternatively show and dismiss the popover, the popover is still
always shown invariably after any dragging happens (either text selection,
or dragging a text handle)
If a textview had lateral windows that might displace the text window, the
handles and popovers would appear displaced. Those lateral windows aren't
affected by RTL/LTR settings, so just checking for left/top is ok here.
This property is TRUE by default, when a popover is modal, it
will automatically set a GTK+ grab on the popover, and grab
the keyboard focus into the popover.
GdkWindows are gone now from the API, the pointed_to rectangle
is from now on relative to the widget allocation. GtkTextView
and GtkEntry were updated to adapt to this change.
The behaviour of gtk_text_view_add_child_in_window() used to be
quite broken. It scrolled with the window during scrolling, then
jumped to the absolute position when the widget resized. Furthermore,
in 3.10 we broke the first feature, making it always be fixed.
The "proper" way to handle this is to always follow scrolling. This
is what the only user so far (gedit) wants, and if you want some
kind of overlay you should use GtkOverlay instead.
So, this changes the behaviour to something that is internally consistent
and works. I.e. all added widgets scroll with the textview as needed.
https://bugzilla.gnome.org/show_bug.cgi?id=711826
GtkSourceView draws before chaining upo to GtkTextView and assumes
that this will be visible, but the pixelcache will just overdraw
that with background.
So, we stop drawing the background to the pixel cache and instead
make it an CAIRO_CONTENT_COLOR_ALPHA surface to make the previously
drawn content see through.
This is slower, but more backwards compatible.
https://bugzilla.gnome.org/show_bug.cgi?id=708423
This allows subclasses of GtkTextView that require a corresponding
subclass of GtkTextBuffer to automatically do the right thing when
constructed with a NULL buffer. An example of this is GtkSourceView
which requires a GtkSourceBuffer.
https://bugzilla.gnome.org/show_bug.cgi?id=708584
Use the pixelcache rendered area to inform what part of the cache should
be invalidated upon changes to the underlying textlayout.
By rendering the background to the pixelcache, we can avoid the need to
use RGBA content.
Also, we're using the pixel cache on the text windows bin_window (see
gtk_text_view_get_window) so we need to register the invalidation handler
on that, otherwise the region passed to the invalidate handler will get
clipped to the visible region.
https://bugzilla.gnome.org/show_bug.cgi?id=707244
