[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    mimetype specific information
From:       Rolf Magnus <ramagnus () zvw ! de>
Date:       2001-10-22 10:05:23
[Download RAW message or body]

I think KDE needs a system to gather some information about files depending on 
its mime type. I'm thinking about small plugins that get the url and return 
information about the file. 
The type of information would depend on the file type. An mp3 e.g. would have 
things like bit rate, ID3 tag information and playing time while a pixmap 
would have e.g. a resolution, bpp and compression type/ratio.

The most flexible way is IMHO returning key/value pairs, so there is no format 
dependant structure to fill in.

This could be used e.g. in the file manager view for tool tips for the files 
that contain information about them. A tool tip for a jpeg pixmap could look 
like this:

+------------------------+
|Resolution:      800*600|
|Bits per Pixel:  16     |
|Quality:         80%    |
+------------------------+

Or it could be used for type specific detailed lists, like nautilus already 
can do. That means, if you have a directory full of mp3s, it would (either 
manually or automatically) show the type specific information in the detailed 
list instead of just general file information. This could look like:

Name        Size    ID3 name           Length   Bitrate 
--------------------------------------------------------
blah.mp3   123456   The great blah     5:42      192
cool.mp3   654321   A cool song        3:27      128

Another use could be information about the file on right click -> properties.
The different mimetypes could have information about where to show which of 
the details in its .desktop file. The .desktop file would also contain a 
mapping between the key and the text that corresponds to it in the different 
languages and, of course, the name of the library that needs to be loaded.

So I'm asking what other people think about it, what the best way to 
implement this would be, or, if I'm totally wrong, how it could be done 
better.

[prev in list] [next in list] [prev in thread] [next in thread]