Storage backend refactoring
This is a very preliminary roadmap/proposal for a major backend refactoring in the Storage panel.
Other than the visual tweaks, the differences between the existing implementation and the mockups is that the former is very file-system dependent when it comes to representing file hierarchies as trees.
The approach we want is similar to the one of Android, where the file types (Content) are more relevant.
Therefore, for instance, instead of showing the size/contents of the $Music folder, we want to show the size/content of music files in the user $HOME. That's not easy to achieve by crawling the file system and extracting/classifying types. Even if so, it is very inefficient.
We already discussed in the past a switch of the backend to Tracker.
In this issue I want to track the efforts towards moving into this new direction.
Examples of Tracker Queries:
$Pictures
tracker sparql -q "SELECT nie:url(?u) nfo:fileSize(?u) WHERE { ?u a nfo:Image . }"
$Videos
tracker sparql -q "SELECT nie:url(?u) nfo:fileSize(?u) WHERE { ?u a nfo:Video . }"
$Music
tracker sparql -q "SELECT nie:title(?u) nie:title(nmm:musicAlbum(?u)) nfo:fileSize(?u) WHERE { ?u a nmm:MusicPiece . }"
All the other info types can be obtained by querying the proper ontology. See https://developer.gnome.org/ontology/stable/nie-InformationElement.html
We should have a query builder class which will be able to lookup for files with the characteristics we need (types and/or locations).