Date: Wed, 28 Apr 1999 17:14:16 -0700 From: Darryl Okahata <darrylo@sr.hp.com> To: freebsd-hackers@freebsd.org Subject: Re: Adding desktop support (please don't) Message-ID: <199904290014.RAA24394@mina.sr.hp.com> In-Reply-To: Your message of "Wed, 28 Apr 1999 14:26:15 EDT."
next in thread | raw e-mail | index | archive | help
Chuck Robey <chuckr@picnic.mat.net> wrote:
> Agreed, but I think you're missing the point. It's not the HAVING of a
> resource fork that's the key, any programmer working in isolation can
> have that. It's the having a standard place to stick those resource
> forks, and a standard method to get and find them, that's the key thing.
Other key points:
* With icons in the binary, maintainance is easier ("How much easier?",
is another issue, though). It's much easier to maintain icons if
they're attached to the executable. Also, among other things, you
don't run into the problem of having out-of-date icons when upgrading
binaries.
[ Yes, in theory, things like this don't happen with proper
installation procedures, but they're all too common in real life. ]
* Probable less disk space. It sounds as if adding an icon to an
executable will only add a few tens of bytes. If you make the icon a
separate file (per icon), the disk space requirements skyrocket
(what's the default frag size for FFS -- I forget?). Of course, you
could have an icon database to get around this, but you make icon
maintanance much more difficult. Disk space is also pretty cheap
these days but, if people are screaming over a piddly few bytes,
they'll scream even louder when you start talking about Kbytes.
--
Darryl Okahata
darrylo@sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, or of the
little green men that have been following him all day.
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?199904290014.RAA24394>