Re: GtkToolbar drag and drop

[Soeren Sandmann <sandmann daimi au dk>]

Federico Mena Quintero <federico ximian com> writes:

> >         * Make the application responsible for handling drops on the
> >           toolbar. This means remove all drag_motion handler etc. from
> >           the toolbar and require the application to implement it
> >           through the standard gtk_drag_* API.
> 
> This would be quite a pain in the butt.  It should be possible to extend
> or completely override what a widget can take as drops.  Imagine that
> toolbars take in data of type "application/x-gtk-toolbar" by default. 
> One should be able to do something like this:

Unless I'm misunderstanding you, that's exactly what the proposed API
is like. The toolbar will with the proposed API simply not have a
"drag_motion" handler. If an application want to drop things on the
toolbar, it will _have_ to call gtk_drag_set_target() with an
appropriate set of types, and it will _have_ to connect to
"drag_motion".

Basically the toolbar would be like any other widget wrt. drag and
drop with the exception that it can do fancy highlighting through

        gtk_toolbar_[un]highlight_drop_location()

>   static gboolean
>   drag_motion_cb (GtkWidget *widget, GdkDragContext *context,
> 		  gint x, gint y, guint time_, gpointer data)
>   {
>     if (gdk_drag_context_has_type (context, "text/uri-list")
> 	&& (context->actions & GDK_ACTION_COPY)) {
>       gdk_drag_status (context, GDK_ACTION_COPY, time_);
>       return TRUE;
>     } else
>       return FALSE; /* let the default handler deal with it */
>   }

In addition to the above, the drag_motion_cb() should also call
gtk_toolbar_highlight_drop_location() to make the toolbar indicate
visually where the new item would be placed.

>   static void
>   drag_data_received_cb (GtkWidget *widget, GdkDragContext *context,
> 			 gint x, gint y, GtkSelectionData *sel_data,
> 			 guint info, guint time_, gpointer data)
>   {
>     if (info == TEXT_URI_LIST)
>       add_uri_to_toolbar (GTK_TOOLBAR (widget), sel_data->data);
>     else
>       return; /* Just let the parent handle it */
>   }
> 
> It should be easy to extend the types that a drag destination can
> accept.  In the drag_data_received_cb() above, we also need a way to
> say, "I already handled it; don't do anything", or "I didn't handle it;
> let the default handler deal with it".

The default handler would be "ignore it". Are you saying that we need
a way for several handler to negotiate who handles drag_data_received?
That could be tricky, and I don't really think it's necessary.

Søren