[KimDaBa] Meta-data for files (Was: Proposal for branch project)

jedd jedd at progsoc.org
Mon Mar 22 09:31:17 CET 2004


On Mon March 22 2004 05:44 am, Mikolaj Machowski wrote:
 ] Why? KDE already show previews for txt files (there are still some bugs 
 ] but it is possible). Also "preview" of sound files is done with hovering 
 ] mouse over icon. Visualization is hard but could be done with 
 ] association icon or image with this particular sound file.

 I fit about 50-80 thumbnails on screen while using KimDaBa, and I think
 it would be infeasible to get a visual representation of text documents at
 such a density.

 I was thinking about this last night as I dozed off, too, and realised that
 this facility already exists for text documents on your system - htdig or
 swish++ are two examples.  Summarizing, in text format, a bunch of text
 documents would be painful and pointless.

 Sound file previews .. yes, I've bumped into those accidentally once before
 on KDE.  They didn't last long.  ;)   What kind of information, over and
 above what goes into the file's path, name, or id3 tag, would you want to
 associate with an audio stream?  There's plenty of audio database packages
 out there already, and a lot of them can pull genre and name information out
 of the cddb or equivalent.  (And yes, I know that most people that contribute
 to those public db's can't spell.)  Actually I think the big lack of problem
 here is that so few people create & collect non-music audio files.

 AV stuff is interesting, and I can see it growing in usefulness as more
 people acquire home videos, but I'm still pondering what a useful indexing
 system for an AV collection would look like.

 Anyway, ultimately I really do think this stuff should live in the file
 system layer.

 Jedd.



More information about the KimDaBa mailing list