- Status Closed
- Percent Complete
- Task Type Patches
- Category User Interface
- Assigned To No-one
- Operating System All players
- Severity Low
- Priority Very Low
- Reported Version
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#5160 - Hide directories that have no useful content
In modes like music mode, playlist mode or supported files, the file browser can be cluttered with directories that have unrelated content.
The iAudio firmware, when in player mode, hides directories that have no useful content.
This includes a few root folders that are created by the firmware, on-the-go apps ( http://portableapps.com/suite plug ) and such.
I’d like rockbox to do the same.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
A) How would Rockbox know which folders do or don’t have useful content without scanning your whole drive and identifying if files are music or not?
B) Why not just flag those folders as hidden. In the modes that aren’t “Show All” files and folders with the hidden attribute are not shown.
B> I didn’t think of that; I’ll use that for now.
A> I think the dircache is the ideal place for that, since it does scan the directory tree at boot and updates it whenever a change occurs.
DirCache is a bad idea in my opinion. The goal of DirCache is to offer the exact same view when it’s on as when it’s off. At the moment DirCache doesn’t have to distinguish between files, it just has to create a map of the filetree. So the options are “Have DirCache treat your files differently when it’s on, than the normal browser does when it’s off” or “Make DirCache have a ‘view files option’ that you don’t have when it’s off, and take slightly longer to generate” or “Make browsing take more CPU because folders have to be scanned when entered.”
Indeed, this makes dircache less transparent than it used to be.
But it doesn’t make it less useful.
If you look at it from a “minimal intrusiveness” point of view (aka maximum reuse, aka maximum laziness), using dircache makes sense.
The patch I’m including:
I forgot to add:
Here is a second iteration of the patch.
It uses the dynamic update hooks, has been tested on the real thing, and does not visibly impact startup performance (8s to build the dircache with or without, with playback at startup disabled, for ~5000 entries).
The deep filtering is updated when files are created, moved, or copied; removes have no effect (they do not cause their parents to be filtered), but I don’t feel it’s a really a problem. It could be solved by storing slightly more info (3 ints instead of an enum) in entries.
I’m happy with that patch, and I’d like to propose it for inclusion.
Implementation details:
the patch adds an enum field to every directory entry, which in case of files contains their filter level (as seen in the “show files” selector or the quick menu), and in case of directories contains a filter level which is greater to each of the children’s levels. The filtering done in the file list has been changed to just use this field instead of asking the type. The field has the same lifecycle as the rest of the dircache, which means it is dynamically updated whenever files are renamed, moved, and created. The init sequence has been changed so that the type code is initialised before the dircache.