In which Aaron attempts to learn about and promote a specific feature.
A dynamically filled in selection box that allows the user to select which meta-data is shown in a file manager (Dolphin). And views that show this metadata.
Example metadata: bitrate, encoding-methods, horizontal resolution, vertical resolution, horizXvert-area, polygon-count (for 3d models), author, number of pages,album,play-time(for everything from warcraftIII replays to mp3s), person who committed (svn)
Highly customized meta-data, a user would have to create custom ones on their own, but a template for helping people search should be provided, a "file includes text:" or regular expression. (granted this stuff would be slower than snot)
root-directory-- mime-type, parent directory, size, file-name
We will expressly want parent directory as a way to break down later, and be able to have portions of the file name be categories.
Permissions, what happens the meta-data crawler is ran with, say root permissions and the user is bob, and he tries to access andy's stuff. It may be ok to run the indexer periodically as root, but then access to this data needs to be confirmed .
have seporate column for selected or not have seporate preview column
Dialog to select meta data at least: access time, modified time, creation time, author, playtime, bitrate, pages, dimx, dimy, album, genre.
This information can be stored short term in version 1.0
indexer Done at user level (unless as system-wide-search-user is easier)
store the information in a database so it doesn't need to be refreshed, store by inode so if the file gets moved.
capability to have indexer as either root or user.
network integration, If a file is selected by another user is should be visible to another user. (option to share this or not)
The file manager outer window...
has stuff like kfile and kdirmodel There is probably going to be something to do with all of this stuff.
102 * Parses the configuration file "kmetainformationrc" and
103 * updates the visibility of all rows that got their data
104 * from KFileItem.
Strigi looks like it is the tool to gather needed meta-data http://strigi.sourceforge.net/
http://soprano.sourceforge.net/ This looks like it is the tool that will hold the meta data Nepomuk RDF something or other... I don't know why this is different than any other database, but it looks like it fits the bill.
http://doc.trolltech.com/4.2/intro-to-dbus.html http://www.freedesktop.org/wiki/Software/dbus This looks like the way information will be shared between modules.. a direct socket connection to soprano may be also useable if performance is required