Re: Icons, hiding FS and the desktop

"Ben 'The Con Man' Kahn" <> writes:

> 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.)

Programs can pass icons to the window manager through a Property on
the window.  (This is documented in Appendix A of Book 0, which
describes how programs interact with each other and the window

Another solution, which I detailed in a different message would be to
add another section to the ELF binary.  I just did this, adding the
section ".gnome", containg a C file to a copy of my ls binary:

  objcopy --add-section=.gnome=eeprom.c ls

The resulting program works fine.  The file can be extracted with
"objcopy", and probably libelf or libbfd would do the trick too.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]