GNOME Bugzilla – Bug 56467
GtkTreeView drag & drop generates multiple signals
Last modified: 2004-12-22 21:47:04 UTC
When I perform a drag & drop operation in a GtkTreeView, I get multiple signals. In order to see this bug, you must drag and drop a row that can be expanded. Then you get a GtkTreeModel "deleted" and a "range_changed" signal for the row and all of its children. For example, if the row has 5 children, you would get 6 pairs of "deleted" and "range_changed" signals. Then you get one GtkTreeModel "inserted" signal for the parent row. It seems a bad idea for the number of "deleted" signals to not match the number of "inserted" signals. Basically, it doesn't seem a good idea to generate so many signals. If the "inserted" signal is smart enough to know that the signal also applies to all the children, can't the "deleted" and "range_changed" signals also be smart in this way? Generating multiple signals like this creates a problem for the ATK interface since it assumes a "range_changed" signal corrisponds to a change in a cell. And getting multiple signals makes the ATK work very hard needlessly. Since the "range_changed" signal can specify that the range covers multiple rows, shouldn't it use this feature rather than generating multiple "range_changed" signals?
That's weird. I'll look into it
range_changed is gone; The delete/inserted signals seem to be right. I don't see a harm in the row_changed signals. Might be nice to clean up DnD later, but for now, I don't see what I can do now.
Reassigning bugs to new component owner. Sorry for the flood.
I don't really see why this bug is still open.
When a row, which is expandable, is dragged and dropped I see "row-inserted" signals for the row and each of its children and then a "row-deleted" signal for the row. This looks OK to me.