Re: Icons, hiding FS and the desktop

["Ben 'The Con Man' Kahn" <xkahn mail cybersites com>]

On 19 Apr 1998, Stefan Nobis wrote:

> What about the following idea:

...[snip]...

> What about the programs? There should be a little tool which scans the 
> whole filesystem for any executables. Then the tools looks in its
> database for known programs. This ones will get a special icon and
> will automagically placed on the desktop. All other programs may be
> shown in a list (with as much or as less information possible) where
> the user can look for programs not found in the database.
> 
> This way the user gets all his programs and data without ever thinking 
> about direcotrys, /bin, /usr or the like.

	It would seem that there are 4 basic types of files.  
	1) Compiled executables 
	2) Scripts
	3) Images
	4) Random Data

	(Correct me if you think of a new one.)  Each one of these files
need to be handled differently.  

	Compiled executables should always have a default icon.  They
should only be found from the PATH.  (Why do we HAVE a PATH anyway? 
Shouldn't we use it?  This isn't Windows where each program gets its own
directory, and you have to search the whole disk to find them...)  (Plus,
searching the whole disk is problematic anyway...  Think of automouted
directories, NFS, downtime, and, of course, mounted DOS partitions which
mark EVERY file as an executable.)

	How do we make all executables have an icon?  Well, other OSs use
a resource fork, or imbed the icon in the program.  UNIX does this too.
(Run Netscape...  Now iconize it.  What do you see?  An icon!  Where did
it come from?)  Most programs supply icons like this.  Is there a way to
imbed an icon in Gnome programs in a standard way?  Anyway, the icon
should always be changable.  Windows has a standard icon library.  That
sounds like a good idea...  Of course, we already have that in UNIX.  The
pixmap path works as a icon repository.  Why not use it?  (And expand it.)

	Scripts are much harder.  They don't have icons at all.  Maybe
they should get the icon inherited from the interpreter they use.  They
should probably, by default, get a slightly modified icon of their
interpreter...  But we can add a second line in scripts which specify
icons..  Then search for that.  And, of course, we can reassign icons from
the repository.

	Images are easy.  Give them a standard icon, or display them as a
smaller version on themselves.

	Data is also difficult.  Run it through the 'file' command...
Display with apropriate icon.  Ta-da!  (Allow changing the icon.)

> Every folder the user creates on his desktop will be located in his
> homedir, program icons on the desktop are some sort of info-file (like 
> the amiga .info files or the KDE .kdelnk files) which says gnome which 
> executable to start, what icon to show and the like. These should be
> hidden files (like .program.gnomelnk), so the user will only see the
> programs icon.

	Think of these as scripts...  If they ARE scripts then they are
very flexible.  They can find, and run a program.  They have a pointer to
an icon.  (Or embed it.)  They can do option checking.  They can be
displayed in a graphical file browser.  OR they can be run from the
command line...  And they can be used by anyone!  In this case, maybe it
isn't a good idea to make it hidden....  Maybe give each user a ~/bin
directory?

> I think this is better than an extra .directory tree cause it is
> better controlled what will be located where (not from the users point 
> of view, he should not be aware of this, but from the sysadmins point
> of view). Also a new user have not to first link everythink to his
> desktop (and locate this everything first in the directory structure)
> but when he installs gnome and starts it, he at once will see
> everything which is in his home (and maybe also all in the database
> known programs located in a special programs folder on this new
> desktop from where the user can move them where he wants them to be).

	I'm not sure how useful this is.  An experienced sys-admin will
probably want to setup what beginning users see.  We do this here at
school for example.  A new user should have the setup which was defined
for them.  A HOME sysop should have a lot of hand-holding.  

	Of course, my biggest problem with UNIX has always been the "what
can I do now" syndrome.  A user doesn't know enough UNIX commands to solve
the problems they need.  I'm not sure how to help them.  'apropos' is a
pretty good tool for this, but a gently introduction to UNIX in the
gome-help-browser might help a lot more.

> This way the desktop will be very easy to use. With some good
> installation scripts this will also for the home user, who in most
> cases is his own sysadmin, easy to use, the hole thing will be very
> transparent and i think even easy to uninstall (just kill all the
> .*.gnomelnk or the like files).

> BTW: I´m a teacher for computer beginners here in germany in an
> institution called "Volkshochschule" where the normal people go to
> learn something about computers. And from this point of view i think
> the above mentioned features will be very helpful for this kind of
> people. For the advanced users and sysadmins there are still gmc, the
> console etc. and they will for the not-sysadmin-work also benefit from 
> this kind of desktop (i think).

	Yup.  I've done a lot of teaching as well.  I was involved in LEAP
which goes into the inner-cities and tries to teach kids.  I was a teacher
in the computer center.  It was very eye opening to have to teach 14 year
olds to use the mouse.  
						-Ben

------------------------------------ |\      _,,,--,,_  ,) ----------
Benjamin Kahn                        /,`.-'`'   -,  ;-;;'
(212) 924 - 2220                    |,4-  ) )-,_ ) /\
ben@cybersites.com --------------- '---''(_/--' (_/-' ---------------
 If you love something, write it in C; if it compiles, it is yours; 
                     if it doesn't, it never was.