User:AaronPeterson/MoreMetaDataInDolphin: Difference between revisions

From KDE TechBase
No edit summary
Line 8: Line 8:
==Requirements==
==Requirements==
A dynamically filled in selection box that allows the user to select which meta-data is shown in a file manager (Dolphin).
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:
Example metadata:
bitrate, encoding-methods, horizontal resolution, vertical resolution, horizXvert-area, polygon-count (for 3d models), author, number of pages,
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)
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)
Line 24: Line 27:
* 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 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 expressly want parent directory as a column, and be able to have portions of the file name be categories.


* We will want to be able to sort in this manner:
* We will want to be able to sort in this manner:
root-directory-- mime-type, parent directory, size, file-name
root-directory-- mime-type, parent directory, size, file-name


Where we basically have directory like structures that are not directoriesWhere we show every file within a certain root-directory
*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==
==Tools and parts==

Revision as of 06:34, 15 July 2010

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

Strigi

Strigi looks like it is the tool to gather needed meta-data

Soprano

This looks like it is the tool that will hold the meta data

Dbus

This looks like the way information will be shared between modules