Open ivan-mogilko opened 2 days ago
There is a small difference here that the sprite viewer doesn't show the sprites in it's tree but instead they are shown in a different panel. I believe this is done this way because the TreeView from Winforms can slow down considerably if it has too many items - I think beyond 2000 items the slow downs already are perceptible. And usually games have a lot of sprites. This may not matter when trying to come up with such ExtendedTreeView code, but just mentioning in case it's relevant.
Yes of course, the shared control does not have to require items in it. It may work purely with folders too. It's a matter of who fills it with content.
I tried separating a class here: https://github.com/ivan-mogilko/ags-refactoring/tree/362--dragdropfolders-shared
This is a very old request, but somehow never had a dedicated issue opened in this tracker.
The SpriteManager currently allows to drag sprites between folders, but not folders. This makes it impossible to rearrange folders or moved folders into other folders.
Therefore it's proposed to support these two operations in the SpriteSelector's window:
On implementation.
Similar control scheme has already been implemented in #2362 for Project Explorer. After a quick glance on the code, it seems possible to pick the minimal necessary drag'n'drop related code out (and any other code that may be shared, although that would be optional for this task), and create a custom control class derived from the TreeView. That class would handle no other data than its folders and items, expanding, collapsing and dragging them around. EDIT: example of class name:
TreeViewWithDragDrop
.Any behavior that depends on dragged data should be dealt with either