User:AaronPeterson/MoreMetaDataInDolphin

In which Aaron attempts to learn about and promote a specific feature.

http://lists.kde.org/?l=kde-core-devel&m=127900686709023&w=2

http://lists.kde.org/?l=kde-core-devel&m=127905343728252&w=2

Requirements

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)

• Dealing with changing files, if a new file is created or modified. in an area that is being viewed, we want to have the indexer get the info.

• No false information, If a file is changed or just not gotten to yet, we want the meta data filled with something that indicates not known yet...

• If information should be there but is not, we want a blank indicator.

• We will probably want put the ones that people are more likely to find useful at the top of the list.. and not restrict use of most, basically just hide it.

• We will have to determine how much of the meta-data to store permanently (in a database), and how much to throw away at each viewing of the directory. We will have to use the file-changed date

• We will want to be able to sort in this manner:

root-directory-- mime-type, parent directory, size, file-name

• Ability to sort and group with directory like structures that are generated by a query. (limited to files within a certain countable category, like all files in a certain file-system folder, or from a server etc)

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.

• We might have to integrate with FAMD to see if a file is modified.
• We will have to have timers that make it so the computer refreshes screen periodically, rather than on every single file has changed event.
• We will only need to poll the items visible in the view, or at least prioritize only the items visible, then low priority on other ones (unless we are using it as a search parameter)
• We will probably want to have the meta-data grabber store some stuff perminately,
• when we access the meta-data will will want to compare file modification time, with one that is actually recently grabbed.
• We will probably want a temporary database,
• Data size will probably not be a problem on most desktops
• We do not want to exclude possiblity will want a derived capability--or translator-- some files may give x and y dimensions, and some may only give area and x... so we could derive y.

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 .

0.1 goal

have seporate column for selected or not have seporate preview column

1.0 goal

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)

2.0 goal

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.

3.0 goal

network integration, If a file is selected by another user is should be visible to another user. (option to share this or not)

Tools and parts

Dolphin

The file manager outer window...

KIO

has stuff like kfile and kdirmodel There is probably going to be something to do with all of this stuff.

http://websvn.kde.org/trunk/KDE/kdelibs/kio/kfile/kfilemetadatawidget.cpp?view=markup

Strigi

Strigi looks like it is the tool to gather needed meta-data http://strigi.sourceforge.net/

Soprano

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.

Dbus

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