Drag / Drop functionality for Tree View

[Brainsaw]

I had a look and did some tests:

Dropping a node to another tree doesn't work (which is fine IMHO), the tree's member "Dragged" holds the information about the node to be dropped, and for the second tree it's empty so the tree can't insert anything.

I see what you mean with inserting a node at a certain position, but at the moment I just can't find a good way to show to the user when a node is inserted after the hovered node instead of added as a child. In some apps I know it shows the node completely highlighted when the dropped node as added as a child, and a line blow or above if it's inserted there.

I think the idea of changing the "setDraggingAllowed" to a bitfield is a good idea. I have now defined an enum "EGUI_TREE_DROP_FLAGS" which has bitflags (0 == EGTDF_CANNOT_DROP, 1 == EGTDF_ADD_AS_CHILD, 2 == EGTDF_ADD_AFTER, 4 == EGTDF_ADD_BEFORE). The method then gets a u32 parameter built from these values.

I am trying to get something done, but today I can't really think straight forward .

Btw: in my editor I always add the root scene node as child (which cannot be moved), so it's possible to get a node up there

[CuteAlien]

Dropping a node to another tree doesn't work (which is fine IMHO), the tree's member "Dragged" holds the information about the node to be dropped, and for the second tree it's empty so the tree can't insert anything.

Thanks, for checking. Sounds good.

I see what you mean with inserting a node at a certain position, but at the moment I just can't find a good way to show to the user when a node is inserted after the hovered node instead of added as a child. In some apps I know it shows the node completely highlighted when the dropped node as added as a child, and a line blow or above if it's inserted there.

A line for "insert between" sounds good. But if it's too much, then no problem.

I think the idea of changing the "setDraggingAllowed" to a bitfield is a good idea. I have now defined an enum "EGUI_TREE_DROP_FLAGS" which has bitflags (0 == EGTDF_CANNOT_DROP, 1 == EGTDF_ADD_AS_CHILD, 2 == EGTDF_ADD_AFTER, 4 == EGTDF_ADD_BEFORE). The method then gets a u32 parameter built from these values.

Mhm, something like that, I'll have to think about flags some more as well. And maybe we can change addNode to insertNode to prepare for inserting on same level.

I am trying to get something done, but today I can't really think straight forward :( .

No hurry. Took me months to finally check this patch ;-) Not like we're getting payed for this...

Btw: in my editor I always add the root scene node as child (which cannot be moved), so it's possible to get a node up there

Ah OK, so at least there is some workaround :)

[Brainsaw]

On the weekend I finally got to work on it, but I'm not yet finished. I have added a bitfield of what drag and drop functions are available to the tree view node as well, in my case it would be too many events to react to. For the scenes I have it would be like this:

• I show the root scene node in the editor, and nodes may be dragged to be children, but not inserted before or after
• I have a physics world node which must not be moved, it has to be a child of the root node. Children can be added, the node must not be moved
• Decoration objects which do not physically interact with anything have their own node as parent with the same limitations as the world node
• The children of the physics and decoration node can be moved at will
• The phyiscal data of an object is defined by a child node, this node can be dragged to other mesh nodes, but no two physics nodes must exist. To handle this some event handling is necessary

These are just some details that came to my mind right now. I also have some screenshots, it may be a reasonable idea to add some more color definitions

• A background or different text color for the node where a child is inserted after or before
• A backgorund color for the dragged node which indicates that dropping here is not possible

The first screenshot is already known, drop a node as child of another node:


Next image: drop a node behind the hovered:


Finally dropping a node before another node:


As you can see the text is barely readable in the latter two screenshots

[Brainsaw]

Ok, at the moment it keeps driving me crazy. I tried to following:

Code: Select all

void CGUITreeViewNode::addNodeBefore(IGUITreeViewNode *node, CGUITreeViewNode *newNode) {
  newNode->grab();
  if (newNode->getParent()->deleteChild(newNode)) {
    core::list<CGUITreeViewNode *>::Iterator itNode = Children.begin();

    while (*itNode != node && itNode != Children.end())
      itNode++;

    if (itNode != Children.end())
      Children.insert_before(itNode, newNode);
    else
      Children.push_back((CGUITreeViewNode *)newNode);

  }
  else newNode->drop();
}

But after this method the list of children is ruined and nothing works. Any idea what I'm doing wrong?

[CuteAlien]

You probably have to set a new parent for newNode.
And working with indices isn't possible? insertNode with index might be easier than addNodeBefore, addNodeAfter. Even if lists don't have indices usually.

[CuteAlien]

Also for new colors you can just use some constants for now and I'll do the parts to add them to the skin (keeping patch simpler).

[Brainsaw]

I didn't see a method to insert at index in core::list. But I'll try to set the parent once I have time to. And I'll just use some existing constants for the moment for the color. Thanks for the input

[CuteAlien]

Yeah, that's what I meant - list usually don't work with indices. But as you have to write the function here anyway - I thought it might be logically easier to write it as insert because you might get an index for the mouse position easier (not sure, if not forget what I write here).
So you don't have to think about finding previous/next element on call, but handle that inside the function you call (just loop over elements and increase a counter). And adding to end of children as before is then just an very large index (cast -1 to u32).

But if it's simpler the way you do it - go for it :-)

[Brainsaw]

I have uploaded a new version which seems to work: https://forumdata.dustbin-online.de/Tre ... Drop_2.zip. It is getting complicated with all those options .

• I have added two enums to IGUITreeView.h, one for the per-node drag / drop options, one for the per-tree options (maybe I should remove one and use the other for both)
• I have added a struct "SGUIDragDropInformation" which contains some basic information about the current drag / drop activity
• A method "getDragDropInformation" was added which returns the struct above if a drag / drop activity is goint on at the moment, "0" if not
• Some setters / getters for the flags
• adjusted the rendering code to look like in the screenshots I posted. Now "EGDC_HIGH_LIGHT" is used as background color for the drop candidate if the node can be dropped and would be added as child if the mouse button was released, "EGDC_3D_SHADOW" if it would be inserted before or after the node and "EGDC_INACTIVE_BORDER" if adding as child is not allowed for the mode. Maybe special colors should be defined for these
• Some members which I added before (e.g. "Dragged") are now in the SGUIDragDropInformation which is present in the tree as a member

I hope it works and a review would be great. After feedback I can modify it to fit.

Btw: I hope I got all the Irrlicht code formatting right this time (forgive if not, but at least I think I used tabs instead of spaces everywhere ).

[CuteAlien]

Thanks! I hope I'll get to it a bit faster this time and on first view formatting looks very good :-)

[Brainsaw]

Sorry for the fast new version, I was updating the test app and realized that I had some stupid beginner errors in, so here is a new version: https://forumdata.dustbin-online.de/Tre ... Drop_3.zip.

The test app now fills both trees so you can see that moving a node within the same tree works whereas moving it to another tree is not supported. It now also writes some information on the events to a listbox in the lower part of the window.

[Brainsaw]

Hi, I finally have started a project (well, rather a framework) which uses the Drag-and-Drop function in the editors. When testing it I stumbled upon a crash so I fixed it and uploaded a new patch file: https://forumdata.dustbin-online.de/Irr ... view.patch

[CuteAlien]

Thanks! And sorry for still not applying it. I wanted to do some changes back then. First I thought amount of flags can be reduced by having a flag like "allow_drop" instead of 2 for insert before/after. So as soon as one node allows it you can drop around it. And other thing was that the line is hard to click - I wanted to give it a few more pixels. Well, so much for the plans... I then didn't touch Irrlicht for months except for minor stuff *sigh*. And that's unlikely to change rest of this year :-( (thought after x-mas I might have some days).

[Brainsaw]

That's totally fine, I am still working on the editor(s), and once they are fine imho I will post the framework in the project announcements, even though it's mainly for myself to reduce the time it takes me to setup a new project