Re: Random idea:
Adam Sampson <azz@gnu.org> writes:
> Just as a contrast, the Amiga Workbench stores a number of useful file
> attributes inside a "<filename>.info" file, including the icon, whether the
> file was a program or a "project" (data file), and if it was a project what
> program to load it with when it was run, and a list of "tooltypes" (string
> attributes), which the OS ignored but can be read by applications, meaning
> that small programs don't need a config file---they just read their
> configuration data out of their .info file (via an API routine).
The .info files of AmigaOS were nice, but in my opinion the direct
mapping file <-> tool is too limited. Say you have a development
environment, and want to advantage of the meta information in the info
files. Then you more or less has to do it like with Lattice (and later
SAS) C, with separate specialized "project files". If I want to have a
plain Makefile, which I want to edit at some times and execute at
other times, the model breaks down. It get even worse on a system with
many users with different preferences (say, some want to edit images
with deLuxe Paint and others with Brilliance).
I think a two level association is a lot better: You associate a file
with its type (this could be a MIME-style media type), and for each
type you should be able to define operations like View, Edit, Execute,
whatever. This should not be a closed list. And the lookup process
should be available from the command line as well. It's just an
example of the "add-an-extra-level-of-indirection"-trick.
The file type is associated with the file itself, i.e. its inode. All
parts of the system use the same mapping (unless people play
translator tricks). This would fit nicely with inode property list,
but I'm sure there are other ways to implement it. The second mapping,
from file type to "actions", has to be configurable on a per user and
per process basis.
I suspect Debian's update-alternative suck the same way as the global
file <-> tool mapping on the Amiga. System level defaults is the wrong
way to handle user preferences (if I have misunderstood what
update-alternatives does, please correct this).
That said, things are a really a little fuzzier. On one hand, I seldom
edit any Makefiles anyway, I only edit the corresponding Makefile.in
or .am or some hack of my own that control the generation of the
Makefiles. This is similar to the idea of a Project file like with SAS
C or the common development environments on w*ndows. So I could
perhaps live with a system where clicking on a Makefile always invoke
make. On the other hand, when I wanted to edit a Makefile on the
Amige, I could just drag it into my emacs window (emacs-19.56 back
then), and it worked, despite any Tool association hardwired into the
corresponding .info file.
/Niels
Reply to: