Hi Mates,
When dragging a file in a lister on top of a folder that has multiple folders inside of it, I'd like for the folder to automatically expand to show the folders inside of it so that I can drag to the one that I want. I believe that this idea is called spring-loaded folders, just like on Mac OS.
Can DOpus do this? If not, I strongly urge you to implement this feature. It would save enormous amounts of time!
Thanks,
Steve
It can do that in the folder tree (search for "spring" in the Preferences dialog and it will highlight the option).
Hi Leo,
I'm specifically interested in being able to do this in the lister, as in the screen shot, not in the folder tree.
Thanks,
Steve
Hi Leo,
Elsewhere, I wrote: "Also, DOpus advertises spring-loaded folders in the folder tree view, but this isn’t really true. I have a dozen favorites folders that appear in the tree view. When I drag a file over one, nothing happens. There’s no spring-loading. It’s true that this happens for non-favorites folders, but why doesn’t it happen for favorites folders? It should all work the same–consistently. Also, it doesn’t make sense to have (partial) spring-loaded folders in the folder tree view, but no spring-loading of folders in the actual lister views to the right of it. It’s not just that Mac OS does this that’s relevant; it’s good design and saves a lot of time."
You replied: "[F]avorites in the folder tree cannot be expanded at all, by design. The favorites branch of the tree is intended to be a fixed list of shortcuts that stays at the top of the tree, so the list is always in the same place and structure for you to pick a favorite from. If it expanded, it’d become a mess and no more use than the main parts of the tree. As you navigate to another folder from a favorite (e.g. the child of a favorite), the tree jumps to the real location of that folder. So the spring-loaded option doesn’t apply there as those nodes in the tree don’t expand. I guess they could just when doing drag & drop, but it’s not something anyone else has asked for so far."
Yes, I want to bitterly complain! 
(At least I'm consistent--right?)
I commend you for trying to implement spring-loaded folders. Let's step back for a moment. What's the problem that we're trying to solve with spring-loaded folders? It's to drag and drop files or folders from one place to a specific folder, buried somewhere inside a higher-level folder, as efficiently as possible. Do you agree? (If not, why bother with spring-loaded folders at all?)
If we agree on that goal, then the question is: What's the best way to do that?
One possibility is to create a favorite folder for every possible folder that one would want to typically perform the drag-and-drop operation to. That gets unwieldy, though, if you have dozens of such folders and need to scroll the folder tree view. (Principle: minimize scrolling.) It would also put a tremendous burden on the user to keep adding favorite folders. And no user wants to deal with a long list. (Imagine how long scrolling and finding the right folder would take if you have to deal with dozens of them--every single time! Keep in mind the limits of human cognition: we can only store between five and nine items in short-term memory, on average; any more, and we become inefficient as the cognitive burden increases.)
Another possibility is to open a two-pane lister, navigate to the source folder in the left pane, navigate to the destination folder in the right pane, and then perform the drag and drop operation. (But that would be highly time-consuming and thus inefficient.)
A third possibility is to drag files or folders from a lister to the folder tree view (not including favorites folders, where spring loading doesn't work), which will expand as you drag. But this requires a lot of scrolling and mouse movement.
If using the UI, the most efficient operation that I can think of, borrowing shamelessly from the Mac OS Finder, is to use spring-loaded folders as implemented by Apple. I think that your implementation of spring-loaded folders in DOpus is both partial and inconsistent.
I understand that you want to use favorites folders as fixed "anchors." But 1 is inefficient. And design is all about figuring out what the user is trying to do and enabling him or her to do it as efficiently and easily as possible, which is what a full-blown implementation of 4 would accomplish.
You, yourself, hit upon the solution when you said: "I guess the [folders] could just [temporarily expand when] doing drag & drop, but it’s not something anyone else has asked for so far." This is the way that the Finder works in Mac OS X, and it's very efficient.
The problem with your partial implementation of spring-loaded folders is that because it only works in the folder tree view, not including favorites folders, and not including listers, not only is it an incomplete feature, but it is an inconsistent feature. It's disorienting to the user to be able to drag-and-drop and have spring loading occur only in the first case, but not in the latter two.
The idea with spring-loaded folders is not for the folder tree view to move around and become unwieldy to work with as it expands and contracts. That would be a usability nightmare. Instead, please take a close look at how Mac OS X Finder works. Apple did things right.
If you implement spring-loaded folders correctly, and apply it consistently across the folder tree view (including favorites folders) and in listers, you'll nail this feature and it will greatly benefit users. In listers, when we drag files or folders over a sub-folder, that folder should expand (reveal sub-folders and files within it) to enable us to hover over another sub-folder, which, in turn, should also expand, and so on, until we reach the target folder that we want and release the mouse over to drop the files into that folder, at which point the lister should show the folder that we started with.
The expansion and contraction would only occur when dragging the cursor (with selected files or folders) over a folder (or nested sub-folder), and the expansion and contraction would be recursive. The moment that a drop occurred, the UI would show the exact same view as right before the user began the drag-and-drop operation.
Fellow users: Am I right?
Vote here!
Leo, also, every time that you want to add or change features, before you write so much as a semicolon, first ask yourself: What goal does the user want to accomplish, and how should DOpus work to enable them to accomplish it as easily and efficiently as possible, far superior to how they could do it in File Explorer, or using any other file management app? Please make your design work about achieving user goals, not just adding features. Design is teleological. What are the user's goals? What's the workflow? Minimize the latter.
Thanks,
Steve
I can see this being a handy feature.
I keep trying not to say this but after the Nth time, could you please try not to patronise us in every post, as if the only reason we have not already implemented the idea you suggested earlier in the day is due to some form of stupidity on our part? We'll be much more open to ideas if you don't. 
We've been writing software, for users, and based on user feedback, for decades. One thing to remember is that you are not the only user and lots of people want lots of different things which sometimes conflict and which, most importantly, always conflict for our time.
As I said (in the other thread), and you quoted (here), it might be a good idea for favorites in the tree to be able to expand temporarily during drag & drop. It's something we will consider, but it is also a non-trivial change (unlike some others we've done today with a quick turnaround) and, at least as far as I can remember, this is the first time anyone has asked for it. Two votes for it so far, and I agree it's not a bad idea as well, so that's a good start. We'll keep the idea in mind for the future. For now, it works the way it works.
Hi Leo,
Sorry. I don't mean to patronize you. I come from an engineering background, and my own tendency is to favor features and complexity while sometimes losing track of human factors, but over time I've come to appreciate the Apple Way (for lack of a better term), even though I use Windows.
I understand that implementing spring-loaded folders as described would be difficult, and that there's demand for all sorts of other features. I hope, and believe, that spring-loading would be a highly marketable feature that would let you reach many more prospective users, and I'm confident that it would be a very highly used feature.
For each person who posts here, I suspect that there's a very large number who are silent but want the same thing. No other file manager app for Windows implements spring-loading as I've described. DOpus would be the first, and it would be a huge competitive advantage that could drive significant sales.
I just want to emphasize that implementing spring loading for favorites folders wouldn't go far enough. Most of all, it needs to be implemented in the listers, no matter which view: Large Icons, Small Icons, List, Details, Details + Thumbnails, Power, Thumbnails, or Tiles.
I don't know if Apple has patented their spring-loaded folder design, in which case doing the same in DOpus could run into legal risks, so you may want to do some research on this.
Best,
Steve
Perhaps we're all in luck. KDE on Linux now supports spring-loaded folders. Look at the video in this article:
When DOpus does, it will be the final word on file management on Windows!
Thanks,
Steve
(I have no interest whatsoever in spring-loaded folders).
That's interesting.
Why is that? Do you never need to efficiently move a file or folder into a sub-folder?
Thanks,
Steve
Let's not have that debate, please.
You've stated your case and ideas and we'll keep them in mind.
I am hesitant to post to this topic due to obvious reasons, so please let's not start another discussion :). I am just dropping in, to cast another vote for a spring-loaded folder like feature in the lister for consideration, since I found no better thread. I come from a Mac background and miss this little convenience since I always forget about the main/powerful method to do this: Dual Panes. And/Or a little temporary drag-and-drop shelf like PathFinder (macOS) has might also be a handy way to appease drag-and-drop afficionados.
This is a massive gap in the product, and an important marketing opportunity that could drive significant new sales. Please implement this in 2018.
