Re: Icons of program
- From: Andreas Kostyrka <andreas ag or at>
- To: raster redhat com
- cc: mobily iternet it, gnome-list gnome org
- Subject: Re: Icons of program
- Date: Sun, 19 Apr 1998 21:26:34 +0200 (MEST)
On Sun, 19 Apr 1998 raster@redhat.com wrote:
> On 19 Apr, Tony 'Merc' Mobily shouted:
> ee will build this tree as it goes around creating thumbnails... all
> transparently.. :) it still makessense to have an icon format..a nd
I wouldn't call it a icon format only. Make it more like the resource fork
of the file. (How it is implemented in the FS doesn't actually matter,
that's a question of the implementation.)
The Mac in this case get's it (at least in the UI) department right.
Consider: Every file has a data and a resource fork, for example
datafile data fork
.datafile resource fork
Benefits: It solves many problems, like file type, icons, etc, and it
allows programs to store their own data concerning a data file in a clean
way.
For example, on a Mac you have a filetype (don't ask me the exact name)
tag, example: HTML, and a Creator tag example: MyPreferedHTMLEditor
This way, a HTML file on the mac when copied to a different mac will still
be recognized as a HTML file, and on the other hand, my own HTML files
will start my own HTML editor by default.
Actually, I'm thinking about doing a grs (*g* GNU resource) library
myself, to make this feasible.
Implementation thoughts:
The library should only define an API, where implementation modules are
plugged into -> This way one can experiment with different formats, and
have sometime support for a special Linux FS, while still supporting
other systems.
Two implementation come to my mind:
- directory based. Make the resource fork a directory.
- libdb. Store it as libdb file.
> place that file there. Thats the placement of the ".info" file.. that
> can be done many ways. I still think we need a nice compact,
> open-designed icon format to place somewhere than can hold user
> preferences like for exectubles the parameters to run the program with,
> or for data files the program to run to "open" that data file etc.
Exactly, but I'd go one step further, and learn from the Mac way. (Macs
are technically not that nice, their development tools s*ck, but the UI
is quite good.)
Not everything is ok with Mac resources (for example we would have to deal
with Architecture specific resources etc. stuff), but the basic idea is
sound in my eyes.
Andreas
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]