From owner-freebsd-hackers Wed Apr 28 20:39:13 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from m4.c2.telstra-mm.net.au (m4.c2.telstra-mm.net.au [24.192.3.19])
by hub.freebsd.org (Postfix) with ESMTP id 85A7114CF8
for <hackers@FreeBSD.ORG>; Wed, 28 Apr 1999 20:39:09 -0700 (PDT)
(envelope-from andrew@lake.com.au)
Received: from m5.c2.telstra-mm.net.au (m5.c2.telstra-mm.net.au [24.192.3.20])
by m4.c2.telstra-mm.net.au (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA27329
for <hackers@FreeBSD.ORG>; Thu, 29 Apr 1999 13:39:08 +1000 (EST)
X-BPC-Relay-Envelope-From: andrew@lake.com.au
X-BPC-Relay-Envelope-To: <hackers@FreeBSD.ORG>
X-BPC-Relay-Sender-Host: m5.c2.telstra-mm.net.au [24.192.3.20]
X-BPC-Relay-Info: Message delivered directly.
Received: from areilly.bpc-users.org (CPE-24-192-51-95.nsw.bigpond.net.au [24.192.51.95])
by m5.c2.telstra-mm.net.au (8.8.6 (PHNE_14041)/8.8.6) with SMTP id NAA15097
for <hackers@FreeBSD.ORG>; Thu, 29 Apr 1999 13:39:07 +1000 (EST)
Received: (qmail 38545 invoked by uid 1000); 29 Apr 1999 03:39:07 -0000
From: "Andrew Reilly" <andrew@lake.com.au>
Date: Thu, 29 Apr 1999 13:39:07 +1000
To: Wilfredo Sanchez <wsanchez@apple.com>
Cc: Wes Peters <wes@softweyr.com>,
Thomas David Rivers <rivers@dignus.com>, darrylo@sr.hp.com,
hackers@FreeBSD.ORG
Subject: Re: Adding desktop support
Message-ID: <19990429133907.B38300@gurney.reilly.home>
References: <199904290301.UAA62176@scv4.apple.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4i
In-Reply-To: <199904290301.UAA62176@scv4.apple.com>; from Wilfredo Sanchez on Wed, Apr 28, 1999 at 08:02:37PM -0700
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
On Wed, Apr 28, 1999 at 08:02:37PM -0700, Wilfredo Sanchez wrote:
> | microserfs in Redmond. I think the icons are more an attribute of the
> | file manager, they are a virtual view of the file rather than an
> | attribute of the file.
>
> Um, no. This is how you end up with that stupid thing Windows 3
> did with the PIF thingies or whatever they're called, where what you
> see in the viewer really has nothing to do with what is on the disk.
> You get all sorts of goofy problems that way.
It's true that MS borked that implementation, but at Apple you
have the ?luxury? of having the "one true GUI", which is always
part of the system, which is single-user.
> The icon representation you get in the file viewer (and in other
> tools, hopefully) is a property of the file and belongs bundled
> (somehow) with the file.
It doesn't feel like a property of the file to me. Window
managers happily apply different icons to files right now, when
they don't have one otherwise associated with them. Apart from
anything else, that is one thing that allows window managers and
other GUIs to feel different from one another. Themes are a
natural extension of that.
> You can do the icon-by-file-extention
> trick, but that doesn't get you very far, in particular with files
> like executables, where you don't usually add an extention, unless
> you want the same icon for all files and rename everything cp.exe,
> etc. :-)
We have a file typing scheme that identifies executables very
well, thank you. If there are problems with it, I'd suggest
that ways to tie down file types would be more proffitable.
> The file manager knows nothing of some file I may drop in tomorrow.
> How could that file's icon be a property of the file manager? It's
> supposed to know ahead of time about all files and file types on the
> disk? That's pretty tough to deliver.
No, but if you're designing an icon/GUI standard API---as we are
now---then you can say things like: ``when application foo is
installed in the system, and it doesn't want to get the "generic
executable" icon, then the installation process puts the
default icon in ${PREFIX}/share/foo/icon.{xpm,tiff,gif,png}.''
The file manager, having been taught about the standard, looks
there for icons when it is displaying executables. Of course it
also looks for ${HOME}/.foo/icon.{xpm,tiff,gif,png} too, in case
the user has decided to change their view of things.
--
Andrew
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message