GtkTextHandle is used to indicate both the cursor position
and the selection bound, dragging the handles will modify
the selection and scroll if necessary.
Backwards text selection is also blocked for touch devices,
so the handles don't get inverted positions and possibly
obscure portions of the selected text.
Instead, just draw the children. The cairo code will keep track of
things, so there's no need to track things.
Also, the old code was doing it wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=672544
This can cause lagging when scrolling as it causes us to repaint
on every scroll event. This wasn't historically a great problem,
but with smooth scrolling we get a lot more events, so this
now creates visible lagging on slower machines.
Without any extra supporting code, just adding GTK_SMOOTH_SCROLL_MASK to
the event mask for GtkTextView makes GEdit do the right thing and scroll
smoothly. Lovely.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
https://bugzilla.gnome.org/show_bug.cgi?id=671488
The widget window is usually covered by the bin_window.
Its background color will become relevant when we introduce
kinetic scrolling with overshooting.
The new function provides an API that takes the PangoLayout and index
as input params, this way it handles strong and weak cursors internally
factoring out all code duplicated in the widgets that need to render
cursors.
https://bugzilla.gnome.org/show_bug.cgi?id=640317
When multiple pointers are in play, we need to be careful
not to loose track of the device between receiving a button
press and popping up a menu.
https://bugzilla.gnome.org/show_bug.cgi?id=663396
Add _gtk_button_event_triggers_context_menu() and use it instead
of checking for event->button == 3, so context menus are invoked
correctly on the Mac.
which are SHIFT and MOD2 on the Mac, and SHIFT and CONTROL otherwise.
Use the new define all over the place and rename variables and
members to not say "shift" or "control".
This commit introduces a new setting, gtk-visible-focus, backed
by the Gtk/VisibleFocus X setting. Its three values control how
focus rectangles are displayed.
'always' is equivalent to the traditional GTK+ behaviour of always
rendering focus rectangles.
'never' does what it says, and is intended for keyboardless
situations, e.g. tablets.
'automatic' hides focus rectangles initially, until the user
interacts with the keyboard, at which point focus rectangles
become visible.
https://bugzilla.gnome.org/show_bug.cgi?id=649567
Now instead of invalidating when we create the layout we invalidate
when we realize the widget and we remove the invalidation when
unrealizing. It was pointless too destroying the layout in unrealize
as at the end what we just wanted was to remove the invalidation idles.
In GTK 3.0 it's no longer possible to e.g. pop up something
at a text view's cursor (this wasn't exactly possible before
either without including gtktextlayout, but this is a quite
special need anyway).
