Re: drag and drop in gnome

Daniel Weber <> writes:

> Elliot Lee wrote:
> > On 3 Aug 1999 23:28:12 -0400, Daniel Weber <> wrote:
> >
> > >    I'm trying to implement a sample program that accepts drag-n-drop,
> > >however I'm having a serios amount of difficulty in getting it to work.
> > >I'm working from the xDND specification page and the gtk source, but
> > >haven't gotten anywhere, really.  Questions include:
> >
> > You're digging into the low-level stuff. It's really not that complicated ;-)
> >
> > Setting up a drag source:
> >         Call gtk_drag_source_set() with appropriate params.
> >         Provide an appropriate handler for the "drag_data_get" signal.
> >
> > Setting up a drag destination:
> >         Call gtk_drag_dest_set() with the appropriate params.
> >         Provide an appropriate handler for the "drag_data_received" signal.
> >
> I guess I"m missing what you mean by providing an appropriate
> handler.  In the gtk source it's listed as "drag-data-received"
> (with dash instead of underscore) and I put in a signal handler
> with:

Either '_' or '-' will work - they are treated as  equivalent.
>   gtk_signal_connect(GTK_OBJECT(edit_control), "drag-data-received",
>    GTK_SIGNAL_FUNC (drag_data_received), " drag-data-received");
> The signal handler itself just prints out that it was called.  However, this
> signal handler is never entered.  I am setting the drop with:
> gtk_drag_dest_set(edit_control,GTK_DEST_DEFAULT_DROP, targets,2,

>From the GTK+ RDP:

 The GtkDestfaults enumeration specifies the various types of action that will be taken on behalf of the user for a drag
 destination site.

                        If set for a widget, GTK+, during a drag over
                        this widget will check if the drag matches
                        this widget's list of possible targets and
                        actions. GTK+ will then call gtk_drag_status()
                        as appropriate.

                        If set for a widget, GTK+ will draw a
                        highlight on this widget as long as a drag is
                        over this widget and the wiget drag format and
                        action is accetable.

                        If set for a widget, when a drop occurs, GTK+
                        will will check if the drag matches this
                        widget's list of possible targets and
                        actions. If so, GTK+ will call
                        gtk_drag_data_get() on behalf of the
                        widget. Whether or not the drop is succesful,
                        GTK+ will call gtk_drag_finish(). If the
                        action was a move, then if the drag was
                        succesful, then TRUE will be passed for the
                        delete parameter to gtk_drag_finish().

                        If set, specifies that all default actions
                        should be taken.

I suspect your problem is simply that your are using GTK_DEST_DEFAULT_DROP

> where edit_control is a simple edit control (where I hope to open a file
> someday), and targets is defined as:
>    GtkTargetEntry targets[] = {
>     {"text/x-c",0,1},
>    {"text/url",0,2}};
> I take it from the (rather incomplete) documentation at that gtk is
> doing some checking against the defined targets before signaling the
> application.  However there is no mention of what form the targets description
> should be in.  

They are arbitrary strings - the convention is to use mime
types as is recommended for XDND. But sometimes other things
are useful when communicating with MOTIF apps (e.g., _NETSCAPE_URL).

> I assumed that they would be mime types, but since I couldn't
> figure out what was in the GList in the GDragContext I couldn't even print out
> what gtk was trying to drop.  Remember, the only signal I am getting is the
> drag-leave.  This led me down a wild search of the source code and the Xdnd page
> which has, to this point, led me precisely nowhere. 

I certainly don't think of the source code as self-documenting
(and I wrote it...) and the Xdnd spec is not going to be
useful - GTK+ layers heavily on top of that.

If the existing documentation isn't helpful (beyond the
RDP, also check:

though that's considerbaly out of date) you certainly should
look at existing examples - 

 printer applet
 background properties capplet
 panel (a bit more complicated)
 mc (much more complicated)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]