Date: Thu, 29 Apr 1999 08:34:21 +1000 From: "Andrew Reilly" <andrew@lake.com.au> To: Mike Smith <mike@smith.net.au> Cc: jack <jack@germanium.xtalwind.net>, John Birrell <jb@cimlogic.com.au>, hackers@FreeBSD.ORG Subject: Re: Adding desktop support Message-ID: <19990429083421.A34373@gurney.reilly.home> In-Reply-To: <199904282017.NAA01044@dingo.cdrom.com>; from Mike Smith on Wed, Apr 28, 1999 at 01:17:46PM -0700 References: <Pine.BSF.4.10.9904280927450.22235-100000@germanium.xtalwind.net> <199904282017.NAA01044@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Since the overhead is minimal, and costs nothing at runtime, the
> default would be to build _with_ them. Please focus your worry on
Look, I realise that I'm coming across as a total nay-sayer, and
that's a pity, because I do think that we should be trying to
make the desktop thing work more conveniently. But it seems to
me that this resource-fork argument is missing or avoiding a few
important points, the most important one (to me) is that this is
Unix, a _multi-user_ system.
Unix uses ownership and permissions to protect the system against
whole classes of problems (such as viruses) that plague the exact
same systems that have been held up as shining examples of
resource-fork induced ease of use: Windows, MacOS, and OS/2.
Unix has hier(7), which, when followed, allows us to back up the
mutable bits of our computers easily, without even looking at
the immutable bits.
If you're going to standardise some sort of window-system API,
that's wonderful, but I think that it can be built on _top_ of
the existing, well-organised file system, rather than permuting
that system.
I offer Acorn's RISC-OS as a working example of a minimally
permuted file system that has "resource forks". Admittedly, that
file system has a single 12-bit type associated with files, to
help it figure out what they are, but beyond that, it's all just
plain files and directories. The windowing system and
associated APIs used by applications collude to treat certain
directories "applications". These directories, according to the
API, contain files (at least) "!Boot" "!Run", and often "icon".
Icon is just a regulation-sized pixmap. "!Boot" is usually a
script that does system-registration of the file data types used
by that application, and "!Run" is often a script that sets
environment variables before executing the real program.
Now this model works pretty well, (again, for a single-user
system), but does not fit hier(7) at all.
My argument is basically that the right way to do a desktop under
Unix is more-or-less exactly the way it's done now, but with the
bennefit of standardisation. For application foo, executables go
in ${PREFIX}/bin/foo, system default data goes in
${PREFIX}/share/foo/, install-time configuration goes in
${PREFIX}/etc/foo.rc, and user-specific configuration or state data
goes in ${HOME}/.foo/ or ${HOME}/.foorc. If you're looking for an
icon, it's in ${PREFIX}/share/foo/icon.{xpm,gif,tiff}, unless the
user has overridden the default by creating ${HOME}/.foo/icon.xpm.
The whole lot is registered in /var/db/pkg/foo-x.y/+CONTENTS.
What's so hard about that?
If you're argument is that that's hard to just copy to another
place (something I don't think I've ever felt the need to do),
then you need a tool that uses +CONTENTS. We probably have such
a thing already.
If your argument is that "all of the window managers do it
diferently", you've hit the nail on the head. There _are_
different solutions to this problem. Some superficially or
gratuitously different, some fundamentally different. Getting
them to work together is a tough business, because it involves
human interaction. Meetings. White-papers. Standards.
--
Andrew
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990429083421.A34373>