User:AaronPeterson/MoreMetaDataInDolphin - Revision history

AaronPeterson: remembered hearing about this as a bug long ago

2010-07-21T00:49:35Z

remembered hearing about this as a bug long ago

AaronPeterson: /* Dolphin */

2010-07-15T18:49:52Z

‎Dolphin

AaronPeterson: /* KIO */

2010-07-15T18:38:03Z

‎KIO

AaronPeterson: /* KIO */

2010-07-15T18:32:49Z

‎KIO

AaronPeterson: /* Tools and parts */

2010-07-15T07:53:04Z

‎Tools and parts

AaronPeterson: /* Requirements */

2010-07-15T06:34:04Z

‎Requirements

AaronPeterson at 00:27, 15 July 2010

2010-07-15T00:27:42Z

AaronPeterson: Some stuff i want to see in dolphin

2010-07-15T00:26:17Z

Some stuff i want to see in dolphin

New page

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

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

Example metadata:
bitrate, encoding-methods, horizontal resolution, vertical resolution, horizXvert-area, polygon-count (for 3d models), author, number of pages,

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 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:
root-directory-- mime-type, parent directory, size, file-name

Where we basically have directory like structures that are not directories. Where we show every file within a certain root-directory

==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

← Older revision		Revision as of 00:49, 21 July 2010
Line 5:		Line 5:
	http://lists.kde.org/?l=kde-core-devel&m=127905343728252&w=2		http://lists.kde.org/?l=kde-core-devel&m=127905343728252&w=2

		+	here is the most relevant bug:
		+	https://bugs.kde.org/show_bug.cgi?id=169904

	==Requirements==		==Requirements==

@@ Line 71: / Line 71: @@
 === Dolphin ===
 The file manager outer window...
 === KIO ===

← Older revision		Revision as of 18:38, 15 July 2010
Line 76:		Line 76:

	http://websvn.kde.org/trunk/KDE/kdelibs/kio/kfile/kfilemetadatawidget.cpp?view=markup		http://websvn.kde.org/trunk/KDE/kdelibs/kio/kfile/kfilemetadatawidget.cpp?view=markup
		+	<code>
		+	102 * Parses the configuration file "kmetainformationrc" and
		+	103 * updates the visibility of all rows that got their data
		+	104 * from KFileItem.
		+	</code>

	=== Strigi ===		=== Strigi ===

@@ Line 74: / Line 74: @@
 === KIO ===
 has stuff like kfile and kdirmodel  There is probably going to be something to do with all of this stuff.
 === Strigi ===
 Strigi looks like it is the tool to gather needed meta-data

← Older revision		Revision as of 00:27, 15 July 2010
Line 1:		Line 1:
	In which Aaron attempts to learn about and promote a specific feature.		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		http://lists.kde.org/?l=kde-core-devel&m=127905343728252&w=2

@@ Line 68: / Line 68: @@
 ==Tools and parts==
 === Strigi ===
 Strigi looks like it is the tool to gather needed meta-data
+http://strigi.sourceforge.net/
 ===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
+http://doc.trolltech.com/4.2/intro-to-dbus.html

@@ Line 8: / Line 8: @@
 ==Requirements==
 A dynamically filled in selection box that allows the user to select which meta-data is shown in a file manager (Dolphin).
 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)
@@ 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 want to be able to sort in this manner:
 root-directory-- mime-type, parent directory, size, file-name
-Where we basically have directory like structures that are not directories.  Where 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)
 ==Tools and parts==