Re: Icons of program

[Toshio Kuratomi <badger prtr-13 ucsc edu>]

On Sun, 19 Apr, 1998 at 09:41:40PM +0200, Andreas Kostyrka set free these words:
> On 19 Apr 1998, Stefan Nobis wrote:
> 
> > What wants the user to do? Start programs (like netscape) or edit
> * I want my html file to be recognized still when I've typed .htxl by
>   mistake.

This could be a bug or a feature:: if you have an html file with a .htxl
extension, your web server won't serve it out with the right mime-type either.
:-)  More generalised, though, I tend to agree -- I think that `file` and
/usr/lib/magic are smart enough to gather most file types.  I believe raster
said it would be good to use this mechanism with extensions only as a
fallback.

> * I want netscape started on some docu files, but I want my HTML editor
>   started on my own HTML files. (which happens to be Emacs :) )

This could be done by giving and overriding defaults::
*.html => netscape %1
~/public_html/*.html => vi %1

Even better would be to use regex's instead of shell globbing:
!.html$! => netscape %1
!$HOME/.*\.html! => vi %1

Recognizing file type would be more interesting... either those would be
limited to defaults or we'd have to define some sort of and/or logic:
type:html => netscape %1
type:html && !$HOME/.*! => vi %1

> > files (writing text, painting a picture). What needs he for this task?
> > The data and the programs. The data, on Unix machines, will be located 
> > in the users home dir. Why not directly show the user all of his home
> > (except the hidden dot files). And then the programs. OK, make for
> > every program a .program.gnomlnk file which can be located anywhere in 
> > the users home dir. This way the desktop really represents the content 
> > of the harddisk. Users who sometimes uses the console or the like
> > would not be confused or have to deal with different directory
> > structures. Maybe there should be a system dir like .skel from which
> > some standard .*.gnomelnk files will be copied in the users home dir
> > but why do you need that much extra directory structures?

I resist this idea because it tends to hide what is really on the system.
This is a typically Microsoft philosophy -- it (may) simplify matters in the
beginning, but adds confusion later on (So why don't I see the files on my
desktop now that I've started using the shell?  Where's the netscape file on
my desktop in the filesystem?)  This functionality really needs to be built in
from the ground up (as MacOS does.) not added on to an existing system.

> That's my thought also. Additional information are neccessary.
> But they should be kept as near as possible to the data file, to keep
> the confusion down. Ideas:

What do you mean by "kept as near as possible to the data file?"  If you mean,
keep the meta-info on /bin/ls in /bin/.ls, for instance, then there is the
problem of system-writable versus user-writable directories (which the idea
of a separate hierarchy solves.)  But I'm not sure what else you could mean.
> * name -> .name file
> * name -> .name directory
> * name -> name directory. (That's the NeXT way: Make a whole directory
>                            look like a file in the GUI.)
> 

-- 
badger  \"The Difference between today and yesterday is not so much what has
@prtr-13 \ changed between then and now as what I hope to change by tomorrow."
.ucsc.edu  \~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

PGP signature