Re: Icons and document-types

[Jim Pick <jim jimpick com>]

"Sergey I. Panov" <sipan@mit.edu> writes:

> Jim:
> > Conceptually, for me, icons are easy to do:
> > 
> > 1) First we identify the document type for a document.
> >        (returning an "object")
> > 
> > 2) Then we query that object for the icon.
> > 
> > The object that we query will be smart enough to figure out which icon
> > to use. ...
> 
> I see it as an improvement over KDE scheme, which in turn is an
> improvement over MS way of doing it (I think they use magic types as a
> backup for suffix based document type detection).

I took a brief look at the source for kfm - and they have an awful lot
of code in there for identifying document types.

I get the impression that it isn't exactly a trivial problem.  If the
KDE system looks muddy - it's probably because they didn't know what
they were getting into when they started and had to switch concepts
several times.
 
> In KDE "Objects" with information about particular document type are
> stored in "mimelnk" files. User can have his own "mimelnk" files,
> which supposedly overwrite system-wide settings.
> 
>  Executables there are treated in a slightly different way. I guess,
> they just trys to extract icon out of the file. A few of their
> executable actually have one embeded in them, and they do not extract
> icons out of non-kde programs (e.g. netscape).
> 
>  I guess the way they should be dealt with is to treat executables as
> "kde-links"/"gnome-links"/"objects". E.g. if you copy executable to
> the Desktop or Panel Menu the default "object" should be created there
> with startup command, default icon, etc. Life can be made easier if
> there is there was a data base of the default "objects" ("kde-links"
> in case of KDE) for the most frequently used X applications. As soon
> as such "object" ends up on the Desktop ot on the Panel Menu it can be
> customized and live its own life (be different from the one in the
> default "objects" data-base).

If we have the ability to plug-in multiple handlers into the hook for
doing the document-object -> icon resolution, it should be possible to
build a KDE compatibility handler.

For Gnome, we'll want a pre-defined set of icons for all the different
document types, so a database of some form will be needed.

> PS: Isn't that area under tight control of the gmc team/author
> (M.d.I)?  I wander what Miguel thinks about it? 

If we want real integration across the entire free software spectrum,
it would be nice to come up with some CORBA objects that would work
with all the different file managers.

There must be at least a dozen different file managers.  ie.
dired-mode in emacs counts as a file-manager.  So does kfm.  The Gtk
based "workplace" program (if I remember the name correctly).  Many
other apps (ie. ftp clients) should really be implemented as "modes"
on top of file managers.  There are 5 or 6 I've read about on
c.o.l.a., but haven't tried them.

With a truly integrated scheme - no program would have "Open/Save/Save
As" dialogs.  That means the choice of a file manager would be a user
preference.  So it makes sense to do a lot of work in building a
document-type system that can work across the spectrum.

Cheers,

 - Jim

PGP signature