It's unused. Plain text is not using that framework, neither is
in-process same-display transmission.
So it was only useful for sharing text with custom tags across
applications, and nobody is doing that.
Similar to GtkEntry, add an "Insert Emoji" context
menu item, and add the same keybindings. We don't
add the icon here, since it is not clear where it
would go.
https://bugzilla.gnome.org/show_bug.cgi?id=790029
This is not used by anything yet, but add it now, so people looking at
this new code can make sense of it.
Plus, the documentation mentions it, so better have the docs make sense.
It will be used once we add support for conversions to GDK and allow
doing cipboard/dnd by GValue.
Make sure the API reflects the idea that GdkContentFormats is a set
containing mime types. In particular, treat the object itself as a
plural - it's named content format`S' after all - and therefor use
the correct verb form.
Also make GdkContentFormats keep an array instead of a list, now that
it's immutable.
Instead of allowing people to pass a uint user-data, insist on them
comparing mime types.
The user data was a uint instead of a pointer anyway, so uniqueness
could not be guaranteed and it caused more issues than it was worth.
And that's ignoring the fact that it basically wasn't used.
Instead, add a function gtk_image_set_icon_size() for the cases where
overriding the icon size is necessary.
Treat icon sizes the same way as pixel sizes, too. So gtk_image_clear()
no longer unsets the icon size.
GtkSourceView is not using it, so it's unneeded. And it's certainly
diving deep into event internals of GtkTextView which hinders a proper
gesturization.
The selection bubble is not part of the text windows, so hiding it
during scroll should not be done in the text window code.
Also remove an unused variable that was only set in that code but never
read.
A sideeffect is that we don't set the correct parent window on child
widgets anymore, but that is hopefully going to be fixed once we get rid
of child windows completely.
Change constructors to reflect that.
While doing so, also add a fallback argument to the cursor constructors,
so it is now possible to create cursors with fallback.
It was used to mark css properties that affect widgets with text, but it
caused unnecessary invalidations. E.g. 'color' was marked as
AFFECTS_TEXT but changing just the color of a label should not
automatically queue a resize, which is what the code in
gtk_widget_real_style_updated does.
Replace this flag with GTK_CSS_AFFECTS_TEXT_SIZE and
GTK_CSS_AFFECTS_TEXT_CLIP, which GtkWidget can use only if the widget
actually has text.
Clarifies the code and helps catch invalid enum values before they
propagate further. Also add a comment about why two seemingly legitimate
values are not handled there (they’re handled higher up in the file).
Coverity CID: 1457700
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788787
This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
Those should be interpreted by widget-local gestures, not guessed at a
high level with no notions of the specific context. Users will want
GtkGestureMultiPress to replace these events.
Since gtk+ draws more than the widget and allocates more size to it than
it knows about, this flag doesn't work anymore. Removing it (or setting
it to TRUE for widgets that used to set it to FALSE) fixes drawing
invalidation when these widgets get allocated a new size.
Since setting a clip is mandatory for almost all widgets, we can as well
change the size-allocate signature to include a out_clip parameter, just
like GtkCssGadget did. And since we now always propagate baselines, we
might as well pass that one on to size-allocate.
This way we can also make sure to transform the clip returned from
size-allocate to parent-coordinates, i.e. the same coordinate space
priv->allocation is in.
We now rely on toplevels receiving and forwarding all the events
the windowing should be able to handle. Event masks are no longer a
way to determine whether an event is deliverable ot a widget.
Events will always be delivered in the three captured/target/bubbled
phases, widgets can now just attach GtkEventControllers and let those
handle the events.
The TextIter is passed by pointer for efficiency. We neither need to
modify it, nor should we leave it possible to accidentally do so. So,
it should be passed as a pointer-to-const.
We do not need to go through the heavyweight process of constructing a
TextLineDisplay just to get the direction out of it, when we can simply
use TextIter API to get the text and then get its direction using Pango.
Adapted from a patch by Mehdi Sadeghi for GtkSourceView:
https://bugzilla.gnome.org/show_bug.cgi?id=779081#c20
Using Ctrl + left/right to skip between words, or left/right to cancel a
selection, were causing movement on the screen in the opposite direction
of the glyph on the key. This was surprising and awful UX for RTL users.
This is based on a patch covering the former case by:
Author: Mehdi Sadeghi <mehdi@mehdix.org>
Date: Sat Feb 18 02:16:00 2017 +0000
https://bugzilla.gnome.org/show_bug.cgi?id=136059
This is a problematic struct, and giving direct access to it
has kept us from making improvements to GtkTextView. Drop it
from the public API, together with the auxiliary APIs. If
it turns out that this functionality is needed, we should add
individual getters.
Add a new ::measure vfunc similar to GtkCssGadget's that widget
implementations have to override instead of the old get_preferred_width,
get_preferred_height, get_preferred_width_for_height,
get_preferred_height_for_width and
get_preferred_height_and_baseline_for_width.
And with it, gtk_widget_get_visual() and gtk_widget_set_visual() are
gone.
We now always use the RGBA visual (if available) and otherwise fall back
to the system visual.
adds a paragraph to gtk_text_view_get_pixels_below_lines(),
describing how it can be used together with
gtk_text_view_get_pixels_above_lines() to get the total
amount of line spacing between two paragraphs.
https://bugzilla.gnome.org/show_bug.cgi?id=747206
That would imply the pixelcache monitors the style context for changes
and it doesn't do that.
Its only use case was opacity checks, so add
gtk_pixel_cache_se_is_opaque() instead.
A problem that has been observed in polari is that links in tags
are clickable all the way into the margin. This problem is caused
by gtk_text_view_get_iter_at_position ignoring the return value
of pango_layout_xy_to_index. Instead, pass it back as a boolean
return value. This is technically an API break, but we've allowed
ourselves to change return types from void to gboolean before.
The text view draw function was leaving its cairo context
with a transformation after drawing to all the border windows,
which lead mis-drawing in gitg. Avoid this by moving the
gtk_cairo_transform_to_window call inside the existing
cairo_save/restore calls.
https://bugzilla.gnome.org/show_bug.cgi?id=760942
Derived classes like GtkSourceView with their own ::key-event
handler need access to this, in order to make their keynav
as nice as the builtin one, wrt to caret visibility.
https://bugzilla.gnome.org/show_bug.cgi?id=760748
Instead of having old and new style, now have a GtkCssStyleChange opaque
object that will compute the changes you are interested in for you.
This simplifies change signal handlers quite a bit and avoids lots of
repeated computation in every signal handler.
Use the text CSS node for rendering text, and the selection node
for rendering selected text, avoid gtk_style_context_save, update
states of all CSS nodes, and use the proper states when querying
style properties.
Use a CSS node with name selection, like we do for entries
and labels. Unlike those widgets, we currently don't user
gtk_render_background, but just use the background color.
That will require more effort.
When I added the draw_layer vfunc it accidentally got passed a cairo_t
that was configured with to draw in the viewport coordinate space (rather
than the buffer coordinate space). This makes things unnecessary complex,
because you have to convert between the two.
The pixel cache is shared between the text and the layers, so there is
no way to use draw_layer to get a stationary overlay effect. Thus it makes
much more sense for the draw_layer vfunc to draw in the buffer space.
Just changing this would break ABI for existing code, so this is fixed
by adding new layer types and deprecating the old ones.
Also, we use the new layer types to fix gtk3-widget-factory.
https://bugzilla.gnome.org/show_bug.cgi?id=757856
Otherwise the popopver will be automatically unmapped in
_gtk_popover_update_child_visible() when the X axis (coming more
or less directly from events) goes outside the textview.
We are passing widget coordinates to gtk_text_view_window_to_buffer_coords()
which expects coordinates to be relative to the text window in this case.
This may result in drop coordinates being displaced if the side windows to
the top/left sides are visible and taking space, so the DnD indicator will
point to the wrong position.
This can be seen on gnome-builder and gedit when displaying line numbers.
These days exposure happens only on the native windows (generally the
toplevel window) and is propagated down recursively. The expose event
is only useful for backwards compat, and in fact, for double buffered
widgets we totally ignore the event (and non-double buffering breaks
on wayland).
So, by not setting the mask we avoid emitting these events and then
later ignoring them.
We still keep it on eventbox, fixed and layout as these are used
in weird ways that want backwards compat.
This changes textview to share the style context with the pixelcache.
Doing so allows pixel cache to optimize the surface creation and use
a CAIRO_CONTENT_COLOR instead of CAIRO_CONTENT_COLOR_ALPHA when
appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=754658
Same as we did for the entry in the previous commit.
Previously, we just hid the cursor if a key event was adding text,
but not when you used backspace, or Ctrl-V. Rearrange things so that
we obscure the cursor whenever the buffer contents change while we
are handling key events.
https://bugzilla.gnome.org/show_bug.cgi?id=754535
The purpose of this patch is to fix regressions in GtkTextView
scroll behaviours due to commit d138156.
( addition of padding and margins to the view )
Adding some padding is done by, for example, in inspector css tab with:
GtkTextView {
padding: 10px 10px 10px 10px;
}
and adding margins, by changing one of *-margin properties
( * standing for left/right/top/bottom ) or the corresponding
accessor functions.
Understand that none of these bugs are easy to trigger.
What's happened is that a old and wrong version of the code of the code
( lost in the mean time ) was pushed.
These bugs are best seen with wrap mode set to off.
The commit 8baab8f fix a first regression.
This one is about:
- Cursor going out of the view at line ends instead of being visible
or triggering the horizontal scroll.
- Padding not displayed correctly
when moving cursor at beginning/end of lines
- When horizontal scroll position not at left, cursor can make scroll
by more than one character (you need left padding to see this )
- Moving the cursor arround, the rendered text can be shitted in x or y.
( fixed by converting adjustment float values
to integer before calculations )
It can be observed by going down with the cursor more
than the view height then going up
- retval return value of _gtk_text_view_scroll_to_iter wrong in some cases
In addition, this patch re-factor priv->top_border
in screen_dest.y calculation
Of course, all GtkTextView and GtkSourceView based app were impacted
by these bugs ( gedit for example, see bug 754147 )
https://bugzilla.gnome.org/show_bug.cgi?id=753815https://bugzilla.gnome.org/show_bug.cgi?id=75815
When you move line by line, only padding is
automaticly shown and you need to use Page key to show margin.
This commit also fix cursor going out of the screen bug.
show_or_hide_handles() tries to disable visibility when the popover is
shown, although it triggers a bit late, and lets the handles flash briefly
if both popover and handles try to show at the same time (eg. when
pressing on the selection of a previously unfocused textview, the handles
were previously hidden, so they try to show again on focus in).
The handles might fall outside the visible area, and shouldn't be shown
then. Just call gtk_text_view_update_handles() which will perform these
checks, and keep the handle conveniently hidden.
This was leading to unexpectedly visible handles (and in the
wrong/previous position, the handle code doesn't relocate the widget
it's about to hide) when "select all" was selected in the popover on
a textview needing scrollbars.
and extending the selection beyond the view above and/or below.
The buttons on the popover where stealing the focus from the text
view on click, causing the popover to be dismissed before the action
was taken. Fix this by making the buttons not take focus on click.
Use the drag-started signal to differentiate between drags that
move a handle and taps on a handle. Show the touch selection popup
for the latter, but not the former.
Hide the handles when the popover appears, and brind them back
when it disappears. This will need revisiting if we start using
the popover for mouse interaction as well, where we may not
want handles to show up.
We don't want the popover to appear spontaneously, so eventually
the timeout may go away altogether. For now, shorten it to 50ms,
to avoid rewriting all the places where the timeout is set or
unset.
Update style for touch selection in GtkEntry and GtkTextView
according to https://wiki.gnome.org/Design/OS/Selections
Add 'Select All' to the default actions, change actions
to use icons and move the popover to the bottom. If there is
no selection, just offer to paste.
Text insertion/pasting might trigger scroll, so we'd have to wait
until the text was revalidated and the scrolling truly happened
before we can check the new handle(s) position.
Just use the last coordinates given on XdndPosition/drag_motion() in
order to trigger scrolling.
When running on Xwayland, the pointer position is unknown at this
stage on the X11 side, so the coordinates given here are bogus.
This change avoids both roundtrips and this situation.
https://bugzilla.gnome.org/show_bug.cgi?id=749679
The magnifier is now set enough height to show the line being currently
manipulated, which makes it just big enough to show the layout height at
that size and magnification.
- It is not possible anymore to trigger text DnD through touch, pressing
and dragging from within the selection will instead extend it. Text
shrinking is still available through the handles
- The selection mode for touch is per-word, char-level manipulation is
still available through the handles.
- Tapping within the selection will bring in text handles, and toggle
text selection popover.
This mode could also shrink the selection, plus the starting point would
seem somewhat arbitrary (actually dependent on the dragging direction of
the last selection).
Made this mode more consistent by only allowing it to extend the selection,
only in one direction for each operation, and so it keeps the current
selection as a minimum.
Instead of passing a GdkEvent and let the function figure out whether the
selection should be extended, let that to the caller and just pass a
boolean here.
This is a convenient shortcut for a common case. It is implemented
by adding a .monospace style class to the text view, and letting
the theme decide about the monospace font to use.
- gtk_style_context_get_background_color()
- gtk_style_context_get_border_color()
Those functions shouldn't be used anymore, because they don't represent
anything from the CSS styling we support. The background color often
isn't used due to background images and there are actually 4 different
border colors (1 for each side) - if there isn't also a border image in
use.
Try to tidy up how the background is set on the textview:
*) the .view class should be applied only to the text window, not
to the margins
*) when setting the background on the margins we must use .left etc
*) use context_set_bg instead of manually setting the color
https://bugzilla.gnome.org/show_bug.cgi?id=735368
The timeout ID used to be unset after we got the targets from the
clipboard, but there's still a moment between the clipboard request and
the GDK_SELECTION_NOTIFY event that the ID points to an already gone
timeout.
That gesture is meant to handle clicks on multiple buttons, so unset
the GDK_BUTTON_PRIMARY default. Also, remove unnecessary boilerplate
with the new GtkGestureSingle/GtkEventController defaults.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
An animation may be scheduled while the textview content changed in size, so the resize
queued would just unset the animation and set the adjusments with a current value,
defeating gtk_text_view_scroll_to_iter(). In this case, just avoid the adjustment change,
as there is a target value on the way.
https://bugzilla.gnome.org/show_bug.cgi?id=733406
This allows subclasses to render things below and above the text
in the text view. This allows e.g. GtkSourceView to highlight the
cursor row and to render overlays for colum 80. This used to be done
by rendering before/after chaining up to the parent, but that doesn't
work anymore since the view now renders a background, and due to the
use of the pixel cache.
This reverts commit 1ac13435b7.
We want to instead replace this with special vfunc for drawing
below/above the main text so that gtksourceview can use it.
There was this hack, taken verbatim from GtkCList according to the comment,
that would recursively translate the allocation during scrolling, and set
it on children widgets through the direct gtk_widget_set_allocation() setter.
Since commit 4f89eb05cf, this has caused the wrong clipping areas to children
widgets of a textview. The reasons for this seem lost in time, and the approach
seems indeed wrong for windowed widgets as the repositioning of those windows
couldn't happen.
So replace all of this with just a gtk_widget_size_allocate() call, which does
work ok for the children widgets embedded in the "multiple views" gtk demo, and
ought to work for every other widget.
https://bugzilla.gnome.org/show_bug.cgi?id=732900
Use the adjustment target value when repositioning the cursor, and remove the
checks that ensured the cursor was made onscreen immediately, as there will
be definitely a delay on animated adjustment changes.
When moving the cursor, compare current adjustment value with the post-animation
target value, in order to avoid false "keynav failed" positives as the animation
hasn't started yet, so dx/dy are still 0 at that time.
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
Horizontal scrolling is unusual, but specifying some extra offscreen
space for it in free in the normal case where the viewport is the
same width as the canvas anyway, so lets do it.
This patch uses GtkPixelCache to render the contents of the widget,
and typically a bit more, to an offscreen surface. The pixel cache in
turn manages rendering to the actual surface for the widget.
The current strategy for the size to render is the size of the widget
plus half the height.
https://bugzilla.gnome.org/show_bug.cgi?id=701125
Attached widgets inherit from the style of the widget they are
attached to. This can sometimes have unintended consequences,
like a context menu in the main view of gedit inheriting the font
that is configured for documents, or the context menu of the preview
in the font chooser coming up with humongous font size.
To fix this problem, we introduce a context menu style class
and use it for all menus that are used like that. The theme
can then set a font for this style class.
https://bugzilla.gnome.org/show_bug.cgi?id=697127
This reverts commit b2e666bf8f.
We need to keep cursor blinking configurable for accessibility
reasons.
https://bugzilla.gnome.org/show_bug.cgi?id=704134
Conflicts:
gdk/win32/gdkproperty-win32.c
gdk/x11/gdksettings.c
gtk/gtksettings.c
gtk/gtktextview.c
When trying to drag, we currently the position of the first motion
event to determine where the drag came from. This might be alright
in the case of the old animation, but the data will be inaccurate
if the user has moved the pointer quite a bit since pressing the
cursor to start dragging. While we could monkey patch the GdkEvent
at the widget layer, this is unintuitive and strange.
Add a new API that takes a set of pointer coordinates describing
the origin of the drag. Additionally, adapt most widgets to use
it and use it with correct coordinates.
https://bugzilla.gnome.org/show_bug.cgi?id=705605
We've recently a number of classes wholly. For these cases,
move the headers and sources to gtk/deprecated/ and adjust
Makefiles and includes accordingly.
Affected classes:
GtkAction
GtkActionGroup
GtkActivatable
GtkIconFactory
GtkImageMenuItem
GtkRadioAction
GtkRecentAction
GtkStock
GtkToggleAction
GtkUIManager
We do this by making the ::populate-popup signals a little more
flexible. They used to just accept a GtkMenu as argument, now
they can take a menu or a toolbar. To not break the expectations
of existing callbacks, we only emit ::populate-popup with a toolbar
if the :populate-toolbar property is TRUE.
