Re: Icons of program
- From: Jens Christian Restemeier <jchrr post uni-bielefeld de>
- To: andreas rainbow studorg tuwien ac at
- Cc: gnome-list gnome org
- Subject: Re: Icons of program
- Date: Wed, 22 Apr 1998 12:46:58 +0200 (METDST)
Hi !
> And it probably doesn't store too vital informations, it stores only
> informations about a file, so at worst the file is unusable, and at the
> point that you want to use the information, you've already have the GNOME
> desktop up and running. (What else is the icon of a file needed, or the
> window layout of the app, the creator of a file, etc.?)
Let's see how MacOS does it:
Every program contains a resource, which tells the Finder which files it
understands, and which icon to use for those files. For every new program
this information is copied into an internal database.
Now if it wants to diplay an icon for a file, or launch the program for that
file, it looks into this internal database.
This database can become invalid. What do we do ? On MacOS it's possible
to just kill the database file, and on the next startup the finder will scan
all folders for programs to rebuild the database.
On gnome we can do something similar, just with the unix-way:
we already have the *.desktop files, and KDE has *.kdelnk files. This files
can be "compiled" into a binary database file, which allows fast
identification of files and applications. If this binary database gets
corrupted, it can be
a) killed with something like "rm database" from the shell
b) killed an rebuild on startup of GNOME by an emergency hotkey.
c) rebuild from a menu, if it is good enough to allow a start.
Rebuilding the database is simple: First scan the *.desktop and *.kdelnk files.
Then, if information about a file is requested and it isn't in the database,
the information can be rebuild using the *.desktop information.
I personally think this discussion about a binary registry is useless. It's
always posssible to build a binary registry from a textfile, and to generate
a text representation from a binary registry. And who cares if an icon for a
file is lost, as long as the file is useable.
Jens Ch. Restemeier
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]