From owner-freebsd-hackers Thu Apr 29 6:12:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp2.vnet.net (smtp2.vnet.net [166.82.1.32]) by hub.freebsd.org (Postfix) with ESMTP id C505E14D1B for ; Thu, 29 Apr 1999 06:12:08 -0700 (PDT) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by smtp2.vnet.net (8.9.1a/8.9.1) with ESMTP id JAA04977; Thu, 29 Apr 1999 09:13:20 -0400 (EDT) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by dignus.com (8.9.2/8.8.5) with ESMTP id JAA34356; Thu, 29 Apr 1999 09:12:05 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.9.2/8.6.9) id JAA20991; Thu, 29 Apr 1999 09:12:04 -0400 (EDT) Date: Thu, 29 Apr 1999 09:12:04 -0400 (EDT) From: Thomas David Rivers Message-Id: <199904291312.JAA20991@lakes.dignus.com> To: rivers@dignus.com, rkw@dataplex.net Subject: Re: Adding desktop support Cc: hackers@FreeBSD.ORG In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > At 5:57 AM -0500 4/29/99, Thomas David Rivers wrote: > > I point out that if the executable has no icon in it, then this > > "overrides" from the window manager would come into play, right? > > > > Since the "overrides" have to be there anyway - what's the advantage > > of putting the icon in the exe? > > I think that you miss the hierarchy of "defaults". > > If the USER has specified the icon for the entity, use his, > > else if the AUTHOR provided an icon, use it, > > else if the USER gave a default to the window manager, ... > > else if the WM-AUTHOR, ... > > else use a totally generic icon. > And - my point - which you really made - is that all of the alternatives can't go in the executable, or you begin to have many copies of the executable, or one executable with large repository & information for each user that may run it... both of which can be quite a nightmare. So, the program (the window manager) has to support a mechanism for specifying all of these alternate "locations" in the hierarchy. Given that mechanism - which is a necessity... why would I choose a different implementation technique for one out of the five "locations" you list? What advantage does that bring to the problem? You still have to implement solutions for 4/5ths of the uses. Thus, it seems, that placing information in the executable isn't worthwhile given the description above, as it doesn't really "save" anything. Furthermore, it wouldn't be portable (presumably, this window manager is going to want to run on other UNIXes?) So, the presumed window manager really doesn't have a good reason to use that approach. - Dave Rivers - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message