summaryrefslogtreecommitdiff
path: root/gtk/gtktexthandle.c
Commit message (Collapse)AuthorAgeFilesLines
* GtkTextHandle: Look up for the first child of a scrolled window foundCarlos Garnacho2016-02-241-2/+17
| | | | | | | | | | Text handles use to connect to the first GtkScrollable up the hierarchy so they can be repositioned when scrolling. It makes more sense to look up the first child of a GtkScrolledWindow, it must be an scrollable too, and will be the scrollable that can actually change the position of the text handles. https://bugzilla.gnome.org/show_bug.cgi?id=761676
* text handle: Port to CSS nodesMatthias Clasen2015-11-091-21/+22
| | | | | Use cursor-handle as the element name for the CSS node that is used to render text the selection handles.
* texthandle: Request raising of text handle popovers.Carlos Garnacho2015-11-031-0/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=756670
* texthandle: Ensure handles are invalidated on mode changesCarlos Garnacho2015-10-141-0/+5
| | | | | Otherwise the "cursor" handle stays with "cursor" appearance instead of "selection end" when a text selection is started.
* texthandle: small refactorCarlos Garnacho2015-10-141-6/+10
| | | | These long enums are used too often, shorten things a bit with temp vars.
* texthandle: Fix Y positioning of text handlesCarlos Garnacho2015-10-141-7/+7
| | | | | | | | It is assumed that border.top is the same than pointing_to.height (which equals the strong cursor position), which is not since some time ago. The border calculation has been move on top too, it is now used in the Y position one, and doesn't depend on anything we calculate later.
* texthandle: Fix handle dragging on waylandCarlos Garnacho2015-10-141-8/+23
| | | | | | | | | | | | | Text handles are subsurfaces on wayland, so sort of their own toplevel. This made gtk_widget_translate_coordinates() to bail out there, resulting in text handles being mispositioned and jumpy. To fix this, translate to toplevel GtkWindow coordinates manually, and translate coordinates from there. Along the way, the coordinates reported in ::handle-dragged have been fixed so there is no small jumps in either axis (most noticeable in the X axis when you started dragging, and in the Y axis when moving between lines of different heights.
* gtkwindow: Only allow unrestricted positioning to text handle popoversCarlos Garnacho2015-07-061-1/+1
| | | | | | | | | This behavior has been made optional on add_popover() time, text handles will keep being able to overflow the window, in order to allow text selection on views too close to the window edge. Regular GtkPopovers are reinstaurated to the previous size positioning logic though, that is, limited by the visible area of the window.
* texthandle: Avoid double rendering of background/frameCarlos Garnacho2015-06-171-2/+0
| | | | | gtk_render_handle() already renders background/frame itself, avoid doing this twice.
* window: Add concept of popover "parent"Carlos Garnacho2015-06-171-1/+1
| | | | | | | | | | | This will be the widget that the popover relates to (::pointing-to in GtkPopover, ::parent in GtkTextHandle). Additional API to check the popover/parent relationship between widgets has been added, which will be useful wherever this is necessary in a generic manner. https://bugzilla.gnome.org/show_bug.cgi?id=750993
* Fix return value error in _gtk_text_handle_set_directionTing-Wei Lan2015-06-131-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=750888
* texthandle: Remove knowledge about window bordersCarlos Garnacho2015-06-111-6/+0
| | | | | We need to expand beyond these if necessary, so don't artificially limit things here.
* texthandle: Handle ltr/rtl positioningCarlos Garnacho2015-06-111-1/+28
| | | | | This setting is per handle, as is dependent on the selected text, rather than the locale.
* texthandles: Move start handle to bottomCarlos Garnacho2015-06-111-27/+12
| | | | | | | The asset is going to change to point upwards, so physically place the handle below the text position. https://bugzilla.gnome.org/show_bug.cgi?id=750692
* GtkTextHandle: Improve handle positioningMatthias Clasen2015-06-091-12/+54
| | | | | | When we are close the window edge, we need to shrink the 'invisible border' around the handle to avoid mispositioning it. A fiddly calculation, but it works.
* GtkTextHandle: position handles properlyMatthias Clasen2015-06-091-2/+6
| | | | | Move the handles so that the asymmetric assets align with the start/end of the selection.
* GtkTextHandle: add a drag-started signalMatthias Clasen2015-06-081-0/+10
| | | | This will be used to discriminate drags from taps.
* texthandle: Set prelight state on the pointer-interacted handleCarlos Garnacho2015-06-051-0/+11
| | | | | | This will be useful with the theming changes to come. https://bugzilla.gnome.org/show_bug.cgi?id=750396
* texthandle: Allow setting individual states, and separately to handlesCarlos Garnacho2015-06-051-12/+21
| | | | | | | Now each handle gets its individual current state, and we can accumulate more than one state on these. https://bugzilla.gnome.org/show_bug.cgi?id=750396
* texthandle: Use active state when handles are being draggedCarlos Garnacho2014-12-181-0/+21
| | | | The active state flags is set on both handles when this happens.
* texthandle: Use the handle widget style context for renderingCarlos Garnacho2014-12-181-1/+10
| | | | | | | Using the parent widget context is a leftover of the pre-popover implementation, which used GdkWindows directly. This will make the context reflect widget state, at the expense of changing the selector paths that used to match the handles.
* GtkTextHandle: Better draw() implementationMatthias Clasen2014-07-131-0/+2
| | | | | | Conceptually, text handles are boxes, whose content is a 'handle', so draw background, frame and handle. With this, and the previous commit, the cursor-handle theming in Adwaita now works as intended.
* texthandle: Mind the invisible area when moving the handleCarlos Garnacho2014-05-231-3/+7
| | | | | | The handle is still centered horizontally, but the extra vertical space wasn't taken into account, leading to misplacing the dragging point (and the handle) during motion events.
* texthandle: Make a bigger hit area around texthandlesCarlos Garnacho2014-05-231-2/+11
| | | | | | The hit area now extends to all sides around the handle, instead of just towards where the text is. This makes it easier to grab handles once shown.
* GtkTextHandle: Deal with parent_scrollable going awayMatthias Clasen2014-02-191-0/+4
| | | | | | | Use a weak reference to notice when parent_scrollable is going away. https://bugzilla.gnome.org/show_bug.cgi?id=724392
* texthandle: Update child visibility of handles within scrollablesCarlos Garnacho2014-01-221-3/+39
| | | | | | If the rect a handle points to starts falling outside of the parent scrollable allocation, the handle will be automatically hidden, and shown again when the rectangle is visible too.
* texthandle: Track parent scrollable adjustmentsCarlos Garnacho2014-01-221-1/+108
| | | | | This makes sure texthandles follow the parent if it is contained within a GtkScrollable.
* texthandle: ensure handles are recreated on parent hierarchy changesCarlos Garnacho2014-01-221-3/+62
| | | | | This ensures the handles come out right even if the parent widget is reparented to a different toplevel.
* texthandle: Use GtkWindow private popover API.Carlos Garnacho2014-01-221-4/+4
|
* popover: Fix memory management of popoversCarlos Garnacho2014-01-221-3/+4
| | | | | | | | | | | | | | | | | | | | Popovers are strange in the sense that they aren't attached to a parent directly, they rely on the relative_to widget so the toplevel is shared, and when they have a parent, it is the toplevel itself, not relative_to. This also means that there are conditions where the popover loses it's parent, so they must survive unparenting. The previous code would be floating the last reference as soon as the parent is gone, but it was non-obvious who'd own that reference. So fix this situation by granting the ownership of popovers to their relative_to widget, an extra reference may be held by the toplevel when the popover has a parent, but the popover object will be guaranteed to be alive as long as the parent lives. This way, memory management of popovers is as hidden from the user as regular widgets within containers are, users are free to call gtk_widget_destroy() on a popover, but it'd eventually become destructed when relative_to is.
* texthandle: Fix arguments in ::style-updated callbackCarlos Garnacho2014-01-221-1/+2
|
* texthandle: Remove relative_to APICarlos Garnacho2014-01-221-41/+1
| | | | It's unused now, GtkTextHandle uses widget coordinates.
* texthandles: Use GtkWindow popovers APICarlos Garnacho2014-01-221-283/+110
| | | | | | This offers the same behavior, but GDK_WINDOW_TEMP windows aren't used anymore, involving less translations from/to root coordinates, plus no glitches in having handles snap to content as windows move.
* texthandle: Use the parent widget's style contextBenjamin Otte2013-10-051-24/+11
| | | | ... instead of creating our own.
* gtk: Use new macros for defining private dataEmmanuele Bassi2013-07-091-6/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=702996
* texthandle: Set a bigger input shape, covering the line heightCarlos Garnacho2013-03-051-3/+30
| | | | | | | | | | | Now, even if the handles being rendered are small, the handle touch input shape will be as wide as the visible part of the rendered asset, and high enough to cover both the handle and the height of the line where the selection bound is. Also, make handles have the same virtual distance to the line top/bottom when a drag starts, so the handle doesn't jump to another line after a too short threshold.
* texthandles: Keep state internally to avoid X overheadCarlos Garnacho2013-03-051-59/+72
| | | | | | Handles now do sync X calls less often. As visibility state is kept, it now can move+resize+show handles at once instead of in separated steps.
* Add a few missing gtk_widget_unregister_window callsAlexander Larsson2013-02-181-2/+14
| | | | | | | | This was causing warnings on widget unparent like: Gdk-CRITICAL **: gdk_window_has_native: assertion `GDK_IS_WINDOW (window)' failed Becasue the window was not properly removed from the lists on unrealize.
* TextHandle: Don't draw handles if not visibleAlexander Larsson2013-02-071-2/+6
| | | | | | | | | | | | | When calling gtk_widget_draw() on the entry gtk_cairo_should_draw_window() will return TRUE for all windows. This is used when rendering a widget to somewhere other than the screen, and its now used for transparent widgets. This caused the texthandle to always draw itself and terminate the draw handler for the entry. Instead we now only draw the markers when really visible, plus we return FALSE to avoid stopping the entry drawing. https://bugzilla.gnome.org/show_bug.cgi?id=687842
* Add gtk_widget_(un)register_windowAlexander Larsson2013-02-071-1/+2
| | | | | | | | | | | | This replaces the previously hardcoded calls to gdk_window_set_user_data, and also lets us track which windows are a part of a widget. Old code should continue working as is, but new features that require the windows may not work perfectly. We need this for the transparent widget support to work, as we need to specially mark the windows of child widgets. https://bugzilla.gnome.org/show_bug.cgi?id=687842
* texthandles: Add an extra style class to the cursor-mode handleCarlos Garnacho2012-10-261-2/+8
| | | | | | Themes may want to render handles differently depending on whether the widget is in selection mode (2 handles enclosing a selection) or cursor mode (one handle pointing out the insertion cursor).
* texthandles: set input shape on handles' windowCarlos Garnacho2012-10-261-19/+23
| | | | | | | | | | This improves both interaction and theming, as it allows arbitrary handle shapes while just being draggable from the visible areas. This way themes can set up handles with the hotspot visually displaced from the horizontal center, as long as the hotspot lies centered in the image/svg asset.
* texthandle: Fix shape setup on non-composited environmentsCarlos Garnacho2012-10-261-15/+9
| | | | | | The check on the handle to be drawn on the mask was based on the yet to be set priv->windows pointers, pass explicitly the handle position to have the shape correctly initialized on non-composited environments
* Don't create GdkWindows with NULL parentsAlexander Larsson2012-09-271-1/+2
| | | | | This is not multi-display safe, you always need to pick the right parent based on which screen your widget is at.
* Improve CSS styling of touch text selection handlesCarlos Garnacho2012-09-031-11/+28
| | | | | | | Don't hook on the widget style context and set up instead a widget path for itself. Also use a common style class for both handles, with an extra top/bottom class for each handle.
* Add GtkTextHandleCarlos Garnacho2012-09-031-0/+667
This is a helper object to allow text widgets to implement text selection on touch devices. It allows for both cursor placement and text selection, displaying draggable handles on/around the cursor and selection bound positions. Currently, this is private to GTK+, and only available to GtkEntry and GtkTextView.
View Lorry Controller Status