another dnd issue

[Tim Janik <timj gtk org>]

hi owen,

in a SAME_APP dnd scenario with two widgets foo and bar, that
supports target types FOO and BAR and foo being ancestor
of bar, dragging something of type FOO, roughly results in:

- data.callback = gtk_drag_dest_motion;
  gtk_drag_find_widget (, &data);
  // result: data.found == TRUE, info->widget == foo;

- data.callback = gtk_drag_dest_drop;
  gtk_drag_find_widget (, &data);
  // result: data.found == TRUE, info->widget == bar;
  // gtk_drag_dest_drop() has already called gtk_drag_finish()

gtk_drag_dest_motion() works correctly here, foo is able to accept
the FOO-type target. however gtk_drag_dest_drop() prematurely aborts
when checking bar prior to foo due to the following code portion in
gtk_drag_dest_drop():

// widget = bar;
      if (site->flags & GTK_DEST_DEFAULT_DROP)
        {
          GdkAtom target = gtk_drag_dest_find_target (widget, context, NULL);

          if (target == GDK_NONE)
            {
              gtk_drag_finish (context, FALSE, FALSE, time);
              return TRUE;
            }
          else
            gtk_drag_get_data (widget, context, target, time);
        }

      gtk_signal_emit_by_name (GTK_OBJECT (widget), "drag_drop",
                               context, x, y, time, &retval);

      return (site->flags & GTK_DEST_DEFAULT_DROP) ? TRUE : retval;
    }

gtk_drag_dest_drop() shouldn't prematurely call gtk_drag_finish() and
return TRUE if bar can't take FOO, instead, it should give
gtk_drag_find_widget() a chance to carry on and find foo, so i guess that
code should be changed like:


@@ -1688,10 +1733,7 @@ gtk_drag_dest_drop (GtkWidget         *widg
          GdkAtom target = gtk_drag_dest_find_target (widget, context, NULL);

          if (target == GDK_NONE)
-           {
-             gtk_drag_finish (context, FALSE, FALSE, time);
-             return TRUE;
-           }
+           return FALSE;
          else
            gtk_drag_get_data (widget, context, target, time);
        }


---
ciaoTJ