Re: [Nautilus-list] icon and metadata questions

[Darin Adler <darin bentspoon com>]

On 1/4/02 7:31 PM, "Frank Worsley" <fworsley shaw ca> wrote:

> 1. I can't find the Gnome metadata stuff in libgnome-2. I checked it out
> from CVS but there is no gnome-metadata.c/h. I see it is also commented
> out in the nautilus source with #ifdef GNOME2_CONVERSION_COMPLETE.
> Is this deprecated?

It's gone, yes; it was deprecated in gnome-libs 1.2. The only program that
ever used it was gmc.

> 2. Why is there Gnome Metadata and Nautilus metadata? Wouldn't it make
> sense to have only one of the two? Especially since gnome-metadata seems
> to take multiple users, permissions, etc. into account - whereas
> nautilus metadata doesn't seem to. See
> http://www.cygnus.com/~tromey/gnome/metadata.html for more on
> gnome-metadata. 

The file you refer to is a conceptual document about what Gnome metadata
ought to be -- in fact I've never seen it before. Very little of what the
document describes was implemented in the actual gnome-metadata.[ch]. The
gnome-libs implementation used a single database file in the user's home
directory.

Ironically, many of the things the document proposes were done in the
Nautilus metadata implementation. But the proposal is far for complete. For
example, it says that directories owned by the user will "have its own
Berkeley db named ``.metadata''". But there's nothing that says what happens
if the directory's owner is changed.

The actual gmc metadata as implemented only took multiple users into account
in the sense that each user's metadata was completely private -- all stored
in a single database in the home directory. So if one user set a custom icon
for a shared file the others users wouldn't see it. This is one of the
reasons the metadata scheme was changed during Nautilus development. In
addition, all gmc metadata is lost when a directory is moved.

The Nautilus metadata storage is quite similar to what's described in the
metadata.html document. One of the differences is that it accommodates data
that is not simply a value for a predefined key. Some Nautilus metadata is
lists of values.

It would be nice to improve the metadata support further. We can even change
the file format if we do some kind of backward compatibility harness. The
plan is to move the metadata access into gnome-vfs so that it's available to
programs other than Nautilus and retains a notification scheme.

> 3. Why is NautilusMetafile a CORBA object? Is the reason so that it can
> be accessed by other applications and programming languages or is there
> some other reason?

Just as the metadata.html document says, "implementation will have to be
written in a ``thread-safe'' manner as multiple applications could
potentially access the metadata database concurrently". Using a shared
server to read and write the metadata is a basic way to make sure this works
for all processes on one machine. For directories shared across multiple
machines, say with NFS, this scheme is insufficient.

The CORBA object was created as a practical fix for real problems we were
seeing in the late beta versions of Nautilus before 1.0. One Nautilus
component would write to metadata, and the other Nautilus components on the
same machine wouldn't notice the change and were likely to overwrite it.

I would welcome an improved scheme for shared access to the metadata.

> 4. What is a GMC link? Do GMC links store gnome metadata?

The term "GMC link" is used inside Nautilus for the gmc "URL files". These
are simply files with a URL inside them (after a "URL:" prefix). These are
created by gmc when you drag a URL to the desktop, for example. They have no
metadata inside them, but these types of files on the desktop were the one
case that gmc supported custom icons for; gnome metadata for the files
contained the icon name, I believe.

My knowledge of gmc is limited, alas, but that's what I know about it. The
Nautilus support for showing the custom icons for these files was added at
the last minute by Miguel. I would have preferred running a 1-time
conversion tool, since these files are only really supported in the
~/.gnome-desktop directory, but Miguel wanted to do extra work to make it
possible to move back and forth between gmc and Nautilus; I'm not sure how
successful it was.

> 5. Where do we load icon URIs from .desktop files?
> 
> In nautilus_icon_factory_get_icon_for_file we first check if the file
> has a custom icon by calling nautilus_file_get_custom_icon_uri.
> Inside that function nautilus metadata takes precedence over any other
> custom icon (makes sense).
> 
> If there is no nautilus metadata for a custom icon we check if the link
> info for the file has been read (file->details->got_link_info). If the
> link info has been read we use the custom icon from the link info.
> 
> The link info is read inside nautilus-directory-async::link_info_start.
> There we figure out if it is a GMC link or a nautilus link. If it is a
> GMC link we use gnome_metadata_get to read the icon uri
> (link_info_gmc_link_read_callback).
>
> The problem is, I can't find the nautilus-dekstop-file-loader code being
> used anywhere. Where do we try to load these .desktop icons?
> 
> Was the gnome_metadata stuff supposed to load .desktop files?
> If it was, should that be replaced with the desktop-file-loader stuff?

When .desktop file support was added, the programmers who added it
piggy-backed on the Nautilus link functions. So the calls that have names
that make them sound like they work on Nautilus links actually work on two
different kinds of Nautilus links: "historical" links and desktop files.

Thus the code that reads the desktop files is actually
link_info_nautilus_link_read_callback. If you look at nautilus-link.c,
you'll see that it calls through to nautilus_link_desktop_file_* functions.
These functions, in nautilus-link-desktop-file.c, call functions in
nautilus-desktop-file-loader.c.

Ideally, someone would rename these Nautilus link functions for clarity.
Also, in the long run the Nautilus historical link feature is not really
needed, and the desktop file support is presumably what's really going to
stay around.

Among the reasons that the gmc link metadata reading was done differently
from the Nautilus link metadata are: a) the fact that the hackers doing the
work had different styles and chose different approaches and b) the fact
that the gmc link metadata is always in the user's home directory so it's OK
to read it with the gnome-libs calls without using the async. machinery that
works over a slow connection without blocking.

Let me know if you have more specific questions.

    -- Darin