Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GNOME Usage GNOME Usage
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 51
    • Issues 51
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GNOME
  • GNOME UsageGNOME Usage
  • Issues
  • #29

Closed
Open
Created Nov 29, 2017 by Felipe Borges@felipeborgesDeveloper

Storage backend refactoring

This is a very preliminary roadmap/proposal for a major backend refactoring in the Storage panel.

image

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).

Assignee
Assign to
Time tracking