Re: TreeDragSource data_get location

[Torsten Schoenfeld <kaffeetisch gmx de>]

Kevin Ryde wrote:
> I'm tinkering with a DRAG_DATA_GET in a custom treemodel implementing
> TreeDragSource and though to fill the Gtk2::SelectionData using one of
> my sub-objects (or it if possible, and myself if not).
>
> Could the drag_data_get method take a selectiondata object which to
> write to, instead of always making a new one?

After some frustrating hours of reading code and documentation, I'm now
convinced that it doesn't actually make sense to call
Gtk2::TreeDragSouce->drag_data_get without a selection data argument.  The
method is supposed to fill in the selection data *for the target type specified
in the selection data*.  So I think we should apply your patch and actually
deprecate the old calling semantics.

Relatedly: We don't offer any way to construct a Gtk2::SelectionData.  So right
now, you can only meaningfully call things like
Gtk2::TreeDragSouce->drag_data_get when you already have a selection data object
that you perhaps modify and then pass on.  The typical use case seems to be
this: In your drag-motion handler, you need access to the actual selection data
to decide whether a drop is possible.  So you call gtk_drag_get_data which asks
the source for the selection data and then calls your drag-data-received
handler.  There, you have the selection data and can make a decision.

But does this cover all use cases?  Or does it make sense to want to call, say,
Gtk2::TreeDragSouce->drag_data_get to get the selection data for a specific
target type -- without having been passed an existing selection data object from
somewhere?  If so, we'd need to provide Gtk2::SelectionData->new.

It sucks that we don't have tests for all this tree view drag'n'drop stuff.  I
looked into making t/GtkTreeView-Dnd.t non-interactive -- but quickly gave up.
Synthesizing the necessary events seems like hard work.  Can you think of a
walkable way?

-- 
Bye,
-Torsten