Previously, search_folder popped up a window to search for various folder types, and it included a path to distiguish between folders of the same name.
Now that search_folder is integrated into the browser, it no longer shows the folder path. This makes it impossible to know which folders are which when they have the same name.
My use case - I have a MyList folder structure that is organized first by Genre, then by years, then by other common tags (e.g. Intros, Edits). This would mean I could have different genres with the same folder name in it (e.g. Hip-Hop could have an "Intros" folder, and Top 40 could have an "Intros" folder as well).
Before I was able to look at the folder path structure to select the right folder, but now that isn't possible, so I no longer can use this feature as I used to.
Would it be possible to still overlay the folder structure after the folder in a softer font?
Now that search_folder is integrated into the browser, it no longer shows the folder path. This makes it impossible to know which folders are which when they have the same name.
My use case - I have a MyList folder structure that is organized first by Genre, then by years, then by other common tags (e.g. Intros, Edits). This would mean I could have different genres with the same folder name in it (e.g. Hip-Hop could have an "Intros" folder, and Top 40 could have an "Intros" folder as well).
Before I was able to look at the folder path structure to select the right folder, but now that isn't possible, so I no longer can use this feature as I used to.
Would it be possible to still overlay the folder structure after the folder in a softer font?
Posted Sun 07 Dec 25 @ 9:48 pm
Just tried here. Hovering over the results shows the path.
Posted Sun 07 Dec 25 @ 10:27 pm
@groovindj I did more checks after as well - that's only true (you see the path) if the setting tooltip is true or value-only and I normally have that disabled completely.
Knowing the path didn't depend on that setting before - I was wondering if that could still be true by just displaying an overlay of the path next to the folder (it could be done on hover, but regardless of the tooltip setting).
Knowing the path didn't depend on that setting before - I was wondering if that could still be true by just displaying an overlay of the path next to the folder (it could be done on hover, but regardless of the tooltip setting).
Posted Mon 08 Dec 25 @ 12:17 am
I just want to double down on this.
In this new version, I have to enable tooltips, at least on value-only, and then I have to spend a non-trivial amount of time hovering my mouse over multiple folders to figure out which is which, and this was not needed in previous versions (and it seems like a step back in terms of usability).
Even if the overlay only shows when the search bar has content typed into it, and/or it was optional (like a setting to toggle the behavior if not needed) - that would be helpful.
In this new version, I have to enable tooltips, at least on value-only, and then I have to spend a non-trivial amount of time hovering my mouse over multiple folders to figure out which is which, and this was not needed in previous versions (and it seems like a step back in terms of usability).
Even if the overlay only shows when the search bar has content typed into it, and/or it was optional (like a setting to toggle the behavior if not needed) - that would be helpful.
Posted Sat 13 Dec 25 @ 8:38 pm
could do something like this
`browser_window folders ? search_folder ? get_browsed_folder_path : :
as a custom_button name or add a skin element [not sure where in the skin it could go, maybe a horizontal split on the browser that moves the split conditonally.]
`browser_window folders ? search_folder ? get_browsed_folder_path : :
as a custom_button name or add a skin element [not sure where in the skin it could go, maybe a horizontal split on the browser that moves the split conditonally.]
Posted Sun 14 Dec 25 @ 3:27 am
@locodog I agree I can (and probably will) do that for now, but unfortunately it still remains - useability was reduced by the move, and that really shouldn't be the case if the previous behavior was released publicly and was defensible (could be have been depended upon).
Posted Sun 14 Dec 25 @ 6:02 pm
If I may..
I understand your case, but honestly it's an edge user case.
Most people don't use the same folder names all the time.
So, the goal definitely was not to reduce useability, nor I think it was reduced for 99,9% of users.
Yes, your edge case may slipped from the dev team when they decided to change how the feature works, and also slipped from all beta testers that tried the software prior EA release.
For most users though, it become far better than it was.
I believe that after the full release of VirtualDJ 2026 there will be plenty of room for improvements and the dev team can look at your report and decide how to bring back the useability that you lost.
However, still, I believe that the way this feature has changed is a step forward, not backwards.
I understand your case, but honestly it's an edge user case.
Most people don't use the same folder names all the time.
So, the goal definitely was not to reduce useability, nor I think it was reduced for 99,9% of users.
Yes, your edge case may slipped from the dev team when they decided to change how the feature works, and also slipped from all beta testers that tried the software prior EA release.
For most users though, it become far better than it was.
I believe that after the full release of VirtualDJ 2026 there will be plenty of room for improvements and the dev team can look at your report and decide how to bring back the useability that you lost.
However, still, I believe that the way this feature has changed is a step forward, not backwards.
Posted Sun 14 Dec 25 @ 6:11 pm
@PhantomDeejay I agree that integration into the skin was def a step forward, and I definitely appreciate it being done.
However though, not showing the path or some distinguishing trait is kind of assuming users are using unique names for every folder, and probably also even a flat folder structure (where such a decision is more likely to happen).
Looking at it doesn't have to be prioritized at all...I see bigger things on the horizon for what was promised, etc, but was just bringing attention to it, as it does make such a case (same folder names, hierarchichal structure) more difficult to navigate with it.
However though, not showing the path or some distinguishing trait is kind of assuming users are using unique names for every folder, and probably also even a flat folder structure (where such a decision is more likely to happen).
Looking at it doesn't have to be prioritized at all...I see bigger things on the horizon for what was promised, etc, but was just bringing attention to it, as it does make such a case (same folder names, hierarchichal structure) more difficult to navigate with it.
Posted Sun 14 Dec 25 @ 6:20 pm
DJ VinylTouch wrote :
@groovindj I did more checks after as well - that's only true (you see the path) if the setting tooltip is true or value-only and I normally have that disabled completely.
Are there negative side effects or trade-offs when tooltip and value-only are enabled?
Posted Thu 18 Dec 25 @ 2:37 am
So not really - if u have it as tooltip, it shows descriptions of controls and values depending on what you hover over. Value-only shows the values and no description.
It doesn't affect performance negatively, but the overlay could get in the way sometimes.
My issues is that having to enablr tooltips was never a requirement before to differentiate between folders of the same name - the older popup (which is still used for search_playlists) showed the path right beside the folder name. Now, one has to enable tooltips to differentiate, and has to make a conscious effort to hover over each folder and wait for the tooltip to differentiate. When you are at home and calm, that's no big deal, but when you are at a gig and potentially stressed to find the next track, it makes a bigger difference.
It doesn't affect performance negatively, but the overlay could get in the way sometimes.
My issues is that having to enablr tooltips was never a requirement before to differentiate between folders of the same name - the older popup (which is still used for search_playlists) showed the path right beside the folder name. Now, one has to enable tooltips to differentiate, and has to make a conscious effort to hover over each folder and wait for the tooltip to differentiate. When you are at home and calm, that's no big deal, but when you are at a gig and potentially stressed to find the next track, it makes a bigger difference.
Posted Thu 18 Dec 25 @ 2:43 am
Also the search_folder would show previous folders you have been working with, which was a easy way to be working out of multiple folder at the same time. Would deeply appreciate bringing that back
Posted Thu 18 Dec 25 @ 5:28 pm
@devs, it does feel like the quickest way to get this back without breaking the new way is to introduce a "legacy" parameter to search_folders or other verb that brings up the old search box, especially as the old search box still exists for search_playlists.
Posted Thu 18 Dec 25 @ 5:37 pm
search_folder dialog can be used to bring up the old dialog now, and in 8971 right-click on the go to last folder button also brings up this dialog again
Posted Sun 21 Dec 25 @ 7:14 am
@adion many thanks bro
Posted Sun 21 Dec 25 @ 10:43 am
@Adion thanks for bringing that back 🍺
Posted Sun 21 Dec 25 @ 1:41 pm
Yeah thanks Adion. I used the previous interface quite a lot.
Posted Sun 21 Dec 25 @ 3:33 pm
I'd just like to add though, search_folders dialog currently does not respect the options set in search_folders_options.
Posted Sun 21 Dec 25 @ 5:43 pm





