Re: Mime Type Analysis

[David Faure <david mandrakesoft com>]

On Friday 01 December 2000 07:43, you wrote:
> I had a couple of things to add after reading over the Desktop Entry
> Standard. First of all, this thing looks great! With a bit of
> revision, and placing it under the auspices of freedesktop.org, it
> could be way better than the .application files we are using for
> Nautilus right now. In retrospect, inventing a file format for that
> was a bad decision.

The first design is never the right one :-)   We've seen that with KDE 1 too.

> I also thought of a couple of other technical issues while reading
> over this standard:
> 
> * Icons - with the advent of Nautilus, GNOME has the possibility of
>   multiple icons for a mime type at different sizes, in AA and non-AA
>   versions, and with possible state modifiers, such as a special
>   folder for open icons. 

Ok. KDE has different sizes too, alpha transparency since today :), and
overlays (zip, no access for reading, etc), but no open folder thing.

>   Nautilus can also support SVG icons and we
>   hope to make that support gnome-wide. The solution I'd propose is to
>   standardize on storing the name of a 48x48 non-AA PNG icon in the
>   file for the mime type, and construct the names of possible
>   alternate versions from that systematically.

Well, what about putting just the base name of the icon ? The desktop
is then free to map that to whatever version and size of the icon it wants.
Ok, this is a bit biased, it's already what KDE does... but IMHO it's also
the simplest to handle. Icon=html, and then it's up to the desktop
to find the correct icon in the correct directory depending on the size
it wants. 
In KDE it would be $prefix/share/icons/hicolor/48x48/mimetypes/html.png.
But for a 16x16 or a 32x32, it would know where to look.
With the full path (excluding prefix at least!) of a 48x48 icon instead, it 
would have to do smart parsing of the directory, to know where to look
for the other sizes and versions... I guess I misunderstood your idea, 
because I can't see how it would work.
In any case, I don't think that we should make any size default.

> * URI Schemes - GNOME has a virtual file system which will soon be
>   used pervasively; this means that many apps will have the ability to
>   open various URIs. I'd like applications to have a
>   SupportedURISchemes field or the like (netscape would probably list
>   `http:', `ftp:', `file:', etc; a mail client might list `mailto:',
>   etc; we might also need a special value to represent "any URI scheme
>   that gnome-vfs understands", since this is extensible by installing
>   new gnome-vfs modules so apps can't be expected to know all the URI
>   schemes they support at install time). 

Hmm, we do this in KDE simply by having %U after the executable name in the
Exec line. It means "the application uses KIO, so it has full network 
transparency".

For the reason your mention, there's no real need to specify which protocols
it really supports, since this comes from external modules (kioslaves in KDE,
gnome-vfs modules in gnome)....

>   This requires working out
>   whether both the URI scheme and the mime type must be matched, or
>   just the URI scheme and the mime type is irrelevant (as for
>   `mailto:'). It may also be useful to have special icons to represent
>   URI schemes in case we have links to them or visit them, either to
>   avoid remote mime sniffing, because the URI has no assiciated mime
>   type at all (as with `mailto:'), or because it would make the UI
>   look nicer in that particular instance, so we ought to have
>   URIScheme desktop files in addition to application and mime type
>   ones.

This is exactly what KDE's .protocol files are about. I can't really see
the relation with mimetypes though..... We can't standardise that, since
those files describe the capabilities of the code. The code is different,
so the capabilities are different too. If you get a webdav.protocol for KDE,
(and the corresponding kioslave), it doesn't mean that you gnome apps 
just gained webdav support...

> * Nonstandard MIME types - should we try to standardize on this cross
>   desktop? For instance, gnome-vfs has types of x-directory/normal,
>   x-directory/webdav, x-special/device-block, x-special/device-char
>   and the like.

Wow :( Yes, we need to standardize here. KDE uses respectively
inode/directory, [webdav isn't a mimetype], inode/block, inode/chardevice etc.

KDE uses "x-" in the name of the mimetype itself, but never in the name
of the mimetype group, the only groups being used are 
application, audio, image, inode, message, text and video. Currently.

-- 
David FAURE, david mandrakesoft com, faure kde org
http://www.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today
See http://www.kde.org/kde1-and-kde2.html for how to set up KDE 2