GNOME Bugzilla – Bug 705605
Improve the spring-back animation for drag and drop
Last modified: 2013-08-14 11:16:07 UTC
Right now, the drag and drop animation looks awful and chunky. Fix it up to use a tick callback and a smooth, eased animation.
Created attachment 251048 [details] [review] gtkiconview: Remove the border and background from drag icons This doesn't look good when combined with rounded corners on selected items.
Created attachment 251049 [details] [review] gtkiconview: Take padding into account when getting the cursor hotspot This makes the icon view look completely seamless when dragging.
Created attachment 251050 [details] [review] gtkdnd: Use a more modern spring back animation for cancelled drags
Created attachment 251051 [details] [review] gtkdnd: Introduce a new API for more accurate drag origin data 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. As most widgets use a drag threshold to determine when to drag, it should be fairly easy to adapt to the new APIs.
Review of attachment 251048 [details] [review]: looks fine
Review of attachment 251049 [details] [review]: ok
Review of attachment 251050 [details] [review]: ok
Review of attachment 251051 [details] [review]: ::: gtk/gtkdnd.c @@ +2448,3 @@ gint button, + GdkEvent *event, + GdkPoint *coords) GdkPoint ?! I'd rather just take x/y separately. @@ +2639,2 @@ /** + * gtk_drag_begin_full: (method) Do we need that annotation ? I'm almost positive this breaks gtk-doc @@ +2646,3 @@ + * @event: The event that triggered the start of the drag. + * @x: The initial x coordinate to start dragging from + * @y: The initial y coordinate to start dragging from Should say what coordinate system x/y are in @@ +2654,3 @@ + * + * The @event is used to retrieve the timestamp that will be used internally to + * grab the pointer. If @event is #NULL, then GDK_CURRENT_TIME will be used. Should be %NULL and %GDK_CURRENT_TIME @@ +2657,3 @@ + * However, you should try to pass a real event in all cases, since that can be + * used by GTK+ to get information about the start position of the drag, for + * example if the @event is a %GDK_MOTION_NOTIFY. I'd rather say: 'if the event is a motion event' @@ +2679,3 @@ + * Return value: (transfer none): the context for this drag. + * + * Deprecated: 3.10: Use gtk_drag_begin_full() instead. This doesn't belong here
Attachment 251048 [details] pushed as d72252c - gtkiconview: Remove the border and background from drag icons Attachment 251049 [details] pushed as 5674f2c - gtkiconview: Take padding into account when getting the cursor hotspot
Created attachment 251083 [details] [review] gtktextutil: Remove the border and background from drag icons
Created attachment 251084 [details] [review] gtkdnd: Use a more modern spring back animation for cancelled drags
Created attachment 251086 [details] [review] gtkdnd: Introduce a new API for more accurate drag origin data 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.
Uh, the rest of the patches never got pushed.
please push them, then
Attachment 251083 [details] pushed as 2b2162d - gtktextutil: Remove the border and background from drag icons Attachment 251084 [details] pushed as e80d1f0 - gtkdnd: Use a more modern spring back animation for cancelled drags Attachment 251086 [details] pushed as 030b62d - gtkdnd: Introduce a new API for more accurate drag origin data pushed then