Evolutions of file indexing

Nate Graham nate at kde.org
Fri Dec 13 20:00:15 GMT 2019


I think it definitely makes sense to support both, as well as offer an 
option to force the use of old fashioned slow indexing if the user has a 
need for it. However I think we shouldn't be too eager about this, 
because we want the indexing case to work and we don't want people to 
just abandon it and always use the slow indexing. I think that it should 
be somewhat hidden away in the config window, with a warning attached to 
it that it will make indexing slow, and maybe even a request to file 
bugs explaining the reason for wanting to use it.

Nate


On 12/11/19 5:56 PM, Matthieu Gallien wrote:
> Hello,
> 
> Before more changes land related to file indexing, I would like to discuss
> where we want to go.
> 
> To me, we need to support two different ways to get music files depending on
> the platform support and local machine configuration:
> 
> * all music is already indexed by a supported platform specific indexer
> (Baloo, Tracker, Windows Search, Android media content, ...). We should allow
> the user to select that method that will be the fastest ;
> 
> * not all music is necessary indexed (removable device, network path, ...) or
> there is not yet support for the platform indexer (Windows, ...). In this
> case, we should automatically fallback to plain old file system indexing.
> 
> We could a configuration option to force use of plain old file system indexing
> if the user chooses so with a wording like that (to improve):
> 
> [Yes|No] Prefer use of fast search to discover your music (requires that all
> your music is already searchable)
> 
> In all cases, we would try first to get the metadata from the platform
> specific file indexer (like the dolphin metadata widget works).
> 
> What do you think ?
> 
> --
> Matthieu
> 
> 
> _______________________________________________
> Elisa mailing list
> Elisa at kde.org
> https://mail.kde.org/mailman/listinfo/elisa
> 



More information about the Elisa mailing list