Rockbox

Tasklist

FS#5160 - Hide directories that have no useful content

Attached to Project: Rockbox
Opened by Tahn Obu (Tobu) - Monday, 17 April 2006, 12:00 GMT
Last edited by Jonathan Gordon (jdgordon) - Wednesday, 01 August 2007, 14:08 GMT
Task Type Patches
Category User Interface
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

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.
This task depends upon

Closed by  Jonathan Gordon (jdgordon)
Wednesday, 01 August 2007, 14:08 GMT
Reason for closing:  Rejected
Comment by Paul Louden (darkkone) - Monday, 17 April 2006, 19:22 GMT
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.
Comment by Tahn Obu (Tobu) - Monday, 17 April 2006, 19:57 GMT
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.
Comment by Paul Louden (darkkone) - Monday, 17 April 2006, 20:04 GMT
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."
Comment by Tahn Obu (Tobu) - Monday, 17 April 2006, 22:02 GMT
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:
- is against today's CVS
- has been tested in the simulator only (toolchain not ready yet)
- works with all levels of filtering: all, supported, music, playlists;
- hides directories according to the filter when dircache is enabled;
- should speed up browsing slightly (because file type recognition is moved to boot time)
- should slow down boot time slightly for the same reason

Comment by Tahn Obu (Tobu) - Tuesday, 18 April 2006, 07:05 GMT
I forgot to add:
- it doesn't support the dircache's dynamic update hooks yet.
Comment by Tahn Obu (Tobu) - Sunday, 23 April 2006, 17:53 GMT
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.

Loading...