I dont have much problem with the current interface, which highlights the
"slot" in the tree view into which the class/interface/thing will be dropped.
Can you suggest how this might be improved?

Try creating a folder then dragging a class into it, no problems.  Then try
dragging another class into it, it won't go.

If you release the left mouse button near the very bottom
of the folder symbol then there's no problem (at least that
works for me.)

*** Bug 72543 has been marked as a duplicate of this bug. ***

*** Bug 72958 has been marked as a duplicate of this bug. ***

I also just noticed that you cant deposit a class into a package folder
properly unless that package folder is closed. Strange.

*** Bug 75456 has been marked as a duplicate of this bug. ***

I've used 1.1 and am currently using 1.2.  The bug still exists.  Only folders
and packages may contain descendants, so the proper behavior when dragging any
item would be:

1. Check if the destination item can have children (is a package or folder).
2. If true, make the source item a child of the destination item.
3. If false, make the source item a sibling of the destination item.

Problem persists in 1.2.1

*** Bug 57920 has been marked as a duplicate of this bug. ***

*** Bug 83448 has been marked as a duplicate of this bug. ***

Problem persists in kdesdk-040716 (CVS)

Problem persists in kdesdk-040716 (CVS)
additionally the same bug with packegas makes the application useless

Version 1.2.2
Darg to folder works only with collapsed folder. In an expand folder, does not work.

CVS commit by okellogg: 

BUG:57667 - A big round of applause to Ben Burton:
<quote>
The problem is essentially a misunderstanding of the drag/drop mechanism 
when working with trees.  The current umbrello code uses an incompatible mix 
between "drop onto the new parent" and "drop beneath the new parent" semantics. 

The reason some people can't reproduce the bug is that, to reproduce it, 
you need to drop the class over the upper half of the package item in 
the logical tree (i.e., the mouse must end up over the upper half of the 
text, not the lower half).  This causes umbrello to think that you want 
to insert the class beneath the previous tree item intsead, since it 
calculates "new parent node" using code that was really designed to 
calculate "new final position of leaf" instead.  If you drop the class 
over the lower half of the proper tree item, then umbrello behaves as 
you would expect. 

The fix is fortunately quite simple.  [...] Basically you ignore the
slotDropped() arguments altogether, since they correspond to movement
within a tree (drop over the final leaf position), not selection of a
tree node (drop over what will become the new parent node). 

Thanks to Benjamin Mesing for providing a reproducible test case, 
which made it possible to get on top of this one. 
</quote> 


  M +2 -1      ChangeLog   1.71
  M +4 -3      umbrello/umllistview.cpp   1.149


--- kdesdk/umbrello/ChangeLog  #1.70:1.71
@@ -30,5 +30,6 @@
 96216 96221 96964 97155 97182 97697 97887 97984 98603 98899
  99697 100142
-100290 100307
+Version 1.4.1:
+53376 57667 100290 100307
 
 Version 1.3

--- kdesdk/umbrello/umbrello/umllistview.cpp  #1.148:1.149
@@ -1179,8 +1179,9 @@ UMLListViewItem * UMLListView::moveObjec
 
 void UMLListView::slotDropped(QDropEvent* de, QListViewItem* /* parent */, QListViewItem* item) {
+        item = (UMLListViewItem *)currentItem();
         if(!item) {
-                //kdDebug() << "UMLListView::slotDropped: item is NULL - setting to currentItem()"
-                //        << endl;
-                item = currentItem();
+                kdDebug() << "UMLListView::slotDropped: item is NULL - doing nothing"
+                          << endl;
+                return;
         }
         UMLDrag::LvTypeAndID_List srcList;