He was talking about a GUI. You're talking about command line tools.
People who use command line tools are expected to know more and
understand computer concepts a little more than GUI users. That's why
everyone had been complaining about Linux being too hard to use until
the GNOME and KDE systems matured.
Part of the beauty and usefullness of Linux and Unix in general is that
it doesn't "hide" stuff from users with a clue. Yes, you can stick to
your application that knows how to read resource forks and such, but if
you do that then you prohibit users with a clue from using standard
tools on the constituant parts of this compound document because it's
all in a resource fork and there's no way to pull it out unless you
write a custom program.
Or were you and others thinking of rewriting all of the Unix utilities
so that they can handle resource forks. Like a grep that specifies the
resource fork to look through to find files that contain a certain
regular expression.
I don't think what you and others are talking about is the Unix "way"
of doing things. If you want to create another OS then I believe
you're free to fork the tree and add what you want. If you want to
create an application that handles resources in a user-land library
that's fine. However, I don't think what I believe you are advocating
fits in with the paradigm of Unix.
I could be wrong, but that's my current beliefs. I hope I understood
your beliefs in the correct manner (that you support adding resource
fork stuff in the kernel instead of having apps handle this in user
space). If not, I appologize.
> >What part of that can't you understand?
>
> Unless you intend to macify the user interface and force users
> to wade through trackless swamps and climb the Himalayas[1] to
> do anything other than sitting at the console, a "we'll hide it
> in the GUI and the app" approach will fall off the edge of the
> universe pretty quickly.
A couple of questions on what you mean here. (First, I think it should
be MACify or Mac-ify or something - I actually looked up macify at
www.m-w.com and found out it's not a word before realizing what you
meant)
1) Do you mean by "other than sitting at the console" to mean a failure
to be able to do "things" remotely? I think that any GUI interface
that would need anything like resource forks would be written on top of
X ultimately, which should handle any remote issues.
2) If you mean having to use the GUI in order to get the "simpler" view
of the data then I don't see a problem with that. It's kinda like
filesystems themselves now. It's arguably more convienant to look at
an explorer like interface where you can click on folders and move
around pretty conveniently. However, for more experienced users, it
is still "easy" to do more complex things with files using the current
directory symantics. It would be HORRIBLE if someone chose to take
that away and make files only accessible from the GUI.
I'm saying that there is probably a good, easy to use, way of
representing "compound documents" in a GUI for the lay person, but
leave the internals exposed on the command line for more advanced users.
Fred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/