Re: undo/redo

[Russell Nelson <nelson crynwr com>]

Michael K. Johnson writes:
 > Russell Nelson writes:
 > >My feeling is: go for it, and fuck everyone who doesn't use Linux (sorry).
 > 
 > Russell, there are two problems with this:
 >  o  gnome is NOT linux-specific by design
 >  o  if you think Linus is going to accept resource forks, you've got
 >     another think coming.  Please consider reading linux-kernel
 >     archives at www.linuxhq.com on this topic.
 > Linus is right IMHO, but MHO doesn't matter because Linus has said
 > it's not going to happen when plenty of other people have asked for
 > it.

He is right.  Resource forks don't need to be in the kernel; therefore 
they shouldn't be in the kernel.  They aren't supported by foreign
filesystems.  They aren't supported by the common file transfer
protocols: nfs, ftp, rcp, or http.

I thought more about it, and it doesn't need any kernel support.  Not
only that, but it doesn't require Linux.  All that it requires is a
will to lose transparent backward compatibility.  ALL of the schemes
proposed so far lose some sort of backward compatibility.

If you wish only to solve the problem of assigning an icon to a
program, #4 (separate .icon file for each executable) is sufficient.
Users can override the system default by creating a symlink to the
executable in their ~/bin, and a matching .icon file.  The problem is
keeping the .icon with the executable.  People don't install
executables by hand *too* often (when was the last time you did
"cp prog /usr/local/bin"?), so that's not too difficult a problem.

Still, it comes nowhere near solving the problem of associating an
icon with a data file.  If icons are good, then more icons are better.

-- 
-russ <nelson@crynwr.com>  http://web.crynwr.com/~nelson
Crynwr supports Open Source(tm) Software| PGPok |   Freedom is the primary
521 Pleasant Valley Rd. | +1 315 268 1925 voice |   cause of Peace, Love,
Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   |   Truth and Justice.