Re: another dnd issue

[Tim Janik <timj gtk org>]

On 4 Jan 2002, Owen Taylor wrote:

> Tim Janik <timj gtk org> writes:
> 
> > 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, 

> OK, the thing to realize here is that whether a widget is (or subpart
> of a widget) a drop site or not is supposed to be fixed and
> independent of the drag target. If I try to drop something on the
> trash can on my desktop, if it doesn't accept it, it should reject the
> drop, not fall through and land on the desktop.

but that needs to be consistent with motion. if the drag cursor
indicates "i can drop here", because the parent widget returned
TRUE, after the child returned FALSE, the gtk_drag_dest_drop()
should obviously act on the parent (not the child which will
reject the drop).

> Maybe you didn't supply GTK_DRAG_DEFAULT_MOTION and 
> your ::drag_motion handler returned a result that depended on
> the drag type instead of whether the drop location was
> a drop site or not?

yes, this is actually the case, and i see now why it can't work.

i think this needs pointing out in the docs though, basically
they should give a recommendation that either both or none of
(GTK_DRAG_DEFAULT_MOTION | GTK_DRAG_DEFAULT_DROP) should be
specified, since otherwise motion/drop-destination inconsistencies
can occour (i'm not particularly happy that the API allowed this
problem to occour in the first place).

> This code is just like gtk_drag_dest_motion, and is, I believe
> correct.

i fixed things towards implementing drag_drop on my own now while
not specifying any of the flags, and it works fine.

to get back to the topic ;) the other outstanding dnd issues i have
(all still from my "Subject: DND issues", Wed, 8 Mar 2000 email) are:

1) struct _GtkSelectionData should be moved from gtkwidget.h to gtkselection.h
2) during one of my wilder dnd tests, i somehow managed to get
   ::drag-data-received with (context->actions&context->suggested_actions)==0.
   this is nonsense i assume, so there might be a check in gtkdnd.c missing
3) random (though rare) instabilities, e.g. the application ending up with a
   stuck grab

item (1) just needs to be done by sombody, (2) i dno't know the exact
occourances of anymore is the assumption i make there valid?
and i tried to retrigger (3) today.
using gtk in a not-so-fast mode (running beast via ssh localhost beast
is slow enough for me on a pentium 550) and doing lots of cursor motion
before dropping the target, i actually managed to trigger (signal handler
printfs in upper letters):

DRAG_MOTION
position within GtkVBox: xy=153
DRAG_MOTION
position within GtkVBox: xy=29
DRAG_MOTION
position within GtkVBox: xy=-1
DRAG_MOTION
position within GtkVBox: xy=71
DRAG_LEAVE
DRAG_DROP
DRAG_DATA_RECEIVED
position within GtkVBox: xy=71
DRAG_MOTION
position within GtkVBox: xy=139

i.e. it looks like an additional motion event was still queued and
got handled after the drag was finished. i'm not sure how you want
this fixed, ignoring motion events without a former GDK_DROP_START
is probably an option. it should be easy to get around, now you know
what's going on though.

> 
> Regards,
>                                         Owen

---
ciaoTJ