Re: Icons of program

[raster redhat com]

On 23 Apr, Fred Bacon shouted:
->  raster@redhat.com wrote:
->  > 
->  > Well I think it's time for me to chime in again after having
->  > observerd/read everything everyone has said.
->  > 
->  > I still thik (4) is the best solution overall why?
->  > 
->  > * you can't go corrupting a DB.
->  
->  This is really a non issue in my book.  1) A good data base will suffer
->  corruption on only an irregular basis, 2) so long as non vital
->  information is located in the database corruption is irrelevant and 3)
->  so long as you have a failsafe way of reconstituting the database there
->  is no danger.

and chaning anything int he middle of the bd requires re-writing
averyhting after it - random access db's are a pain to do and are
better serverd using the filing system

->  > 
->  > * even ls will indicate that an icon is associated - for file that dont
->  > have icons assigned the FM can dynamically assign them and not have to
->  > create info files (the users ~/gmc/default_icons/*.info can contain
->  > template icons for file times based on magicnumber/extensions (read
->  > magic number - if unknown check extension, if unknown give up and call
->  > the file data) and the fm will ue one of these icons depending on
->  > filetype if no icon exists).
->  > 
->  > * other unix utils can easily move the icons around with the file
->  > without having to go rebuild databases etc.
->  > 
->  > * a filing system is already a reasonably efficient databasing system
->  > on its own.
->  > 
->  
->  Agreed.
->  
->  > * You can't go developing new filing systems like macos's because it
->  > simply isn't protable. Macos isn't a good example 
->  
->  I don't want to duplicate the Mac's file system, just its database. 
->  Trying to emulate the Mac's data+resource fork system is a non starter. 
->  It really isn't even needed.  I would bet that more than ninety percent
->  of the files on my HFS partitions contain information in only one of the
->  two forks.  The other fork is empty.  

thats what i'm saying about .inof files.. if the "fork" is empty..
ooh.. no .inof file there! only if you create a SPECIFIC PURPOSE icons
for that file does it have a .inof file. most files wont even have
.info files cause the ap creating them has 1. no need for them 2.
doesnt knwo it needs to create them.

->  Modifying file formats isn't needed either.  Sticking the icon inside of
->  a file isn't necessary, or desirable.  OpenDoc tried something like that
->  with the Bento container format and it was a disaster.  Perfectly common
->  image format files were unintelligible to non OpenDoc aware applications
->  because they had been wrapped with this unfamiliar Bento format
->  information.  

agreed.

->  When you start out in the minority (as gnome undoubtably will) you can't
->  be incompatible.  Providing additional facilities is good.  Blocking
->  traditional facilities is bad.
->  
->  > this can be fixed as
->  > follows: ".info" file tags along in the same dir as the file - the
->  > filemanager uses this UNLESS there is a .info file in lets say
->  > ~/.gmc/icons/usr/local/pix/water.png.info for a file in
->  
->  Let's say I'm working on a large project. (I believe the program I'm
->  currently working on contains something like 5-600 files--counting the
->  external libraries--in the distribution.)  Are you saying that I would
->  have an additional 5-600 .info files in there as well?  Plus another 300
->  when I compile the *.o files?

no. that woudl mean gcc woudl create them. what would the point be
anyway? the point is if 1. ylu desire a different image for the file
than the default filemanager icon has which isnt put in the dir but
referenced form a repostiry of file-type icons for different file
types.. so the filemanager displays the icons for ".o" files.. but it
doesnt go creating a .o.info file.. NOt unless you edit the porperties
of that icons to have sokmehting other than the default.. ie different
image, options, tooltypes or something unique that the system fm icons
dont have.

->  Your method has some merits, but I would honestly not be willing to use
->  a system that littered my directories with scads of useless files.  One
->  of the reasons that I never use xv's visual schnauzer is that it
->  produces so much clutter.  The fact that /usr/bin isn't cluttered by
->  this technique is irrelevant.  It clutters where I live.  A gui file
->  manager is far less important to me than a tidy home directory.  

if you USE a filemanager u never see the .info files.. - and onyl if
you have extra non default data associated wiht files do you see it.

->  The file manager in KDE is my least favorite component, and its least
->  used feature.  I honestly never use their trash can. (When I was first
->  learning my way around unix, I created a pseudo trash can called .trash
->  and aliased rm to simply mv files into the .trash directory.  Then I
->  wrote a script to pick through the trash and salvage the things I didn't
->  really mean to throw away.  I named it wino. :-)  I do like having icons
->  on the desktop for launching applications, but I don't use their drag
->  and drop facilities because it's too clunky and slow.  Plus, I never
->  know if I've hit my target or not.  A gui interface for my file system
->  is simply not a high priority for me.  Any application which clutters my
->  directories will be history inside of a week. 

now remember,.. we shoudlnt be selfish and think of yourselves.. think
of the USERs.. the peopel who have used a mac or win95 box for years..
they neither know nor care anout the .info file existion.. they just
want a pretty picture.. maybe want to assing different pictures to
files - change how that file is used (ie this image is opened by xv,
this opened by ee, this oopened by gimp) and when they move the file
the icon follows, with proprties.. it's also easy to then xfre files
WITH their properties form one system to another.. just tar up
everyhting... alos useful: icons for dirs:

imagine i had a directory.. and its tool field was "" .. when i drag a
file into it.. it gets moved there... now. imagine i have the tool be
"tar zxvf %s" and i drop somehting in.. what the fm does.. itcd's to
the dir.. runs "tar zxvf filename" - if its a tar file.. ooh presto..
it automagicaly gets untarred form me in my special untar dir.. :) i
can have a dir to unzip.. or un anything. infcat put an intelligent
script "unpak %s" that woprks out if its tar, tar,gz, tar.bz, tar.bz2,
zip, arj, lha, lzh etc. and unpacks it appropriately.. wow .. we now
hve a powerful fielmanager... makinbg the filemanager merely a thing
gui client to display files.. the horsepower is in the intelligent
tool settings... packages of scripts and preset tools (ge the "unpack"
tool could be put in a "tools" dir the fm scans and provides in a
menuor list to chose fomr for standard tools - or you cna type your own
in.. the ones int he menu oif thetool is run wiht -h it outputs a quick
help for the user to read int he gui that reads the help output formt
he tool ect...

->  > now that code, assuming we have an icon struct and a loading routine
->  > (and some other assumed routines) We're set - no database that has to
->  > brebuilt and modified when we delete an iocn in the middle (then have
->  > to repack the data all the way to the end) - thats what filing systems
->  > are for.
->  
->  It's also what a database is for, and of the two a database is more
->  appropriate.  A database doesn't have to be anymore difficult to use
->  than the file system.  
->  
->  It just struck me a few minutes ago that what I have been advocating is
->  really a Corba Service.  It's an interface available for use by any
->  application.

corba isnt going anywhere.. e have a half-function c++ onyl bindigns
orb.. it's missing lots of important stuff.. we can talk abotu corba
all we want.. but we can't USE it til we have an orb that WORKS and
WORKS WELL. I perosnally just advocate rolling out onw ICP mechanisms
as then we'd 1. fully understand them 2. get them finished, 3. be able
to use them in C. Okay.. enouht of my corba/mico bashing.. I'm still a
"do it yerself" person...

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenmenthttp://www.rasterman.com/