From owner-freebsd-hackers Wed Apr 28 11:14:17 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 5902715012 for ; Wed, 28 Apr 1999 11:14:14 -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 OAA08540; Wed, 28 Apr 1999 14:15:11 -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 OAA32643; Wed, 28 Apr 1999 14:13:56 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.9.2/8.6.9) id OAA15682; Wed, 28 Apr 1999 14:13:55 -0400 (EDT) Date: Wed, 28 Apr 1999 14:13:55 -0400 (EDT) From: Thomas David Rivers Message-Id: <199904281813.OAA15682@lakes.dignus.com> To: chuckr@picnic.mat.net, imp@harmony.village.org Subject: Re: Adding desktop support Cc: hackers@FreeBSD.ORG, jb@cimlogic.com.au In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Wed, 28 Apr 1999, Warner Losh wrote: > > > In message <199904281004.UAA27348@cimlogic.com.au> John Birrell writes: > > : The FreeBSD kernel is not affected. I'm not proposing to specify what > > : the desktop looks like, just the information that is made available > > : to the desktop programs. > > > > I really like this idea. For too long there have been too many > > kludges to get around not having this infomation co-located with the > > executable. > > > > After all, we're just talking an icon here. Window managers can > > display it, or override it as they see fit. > > Honestly, even tho it can be done via objcopy, what we need is a API, > something that we guarantee to folks that we won't subtract from > (additions only, and no changing stuff), a standard way to ask a > application for a property, and get back that property, whether that > property is a gif file, or a string, or data. I'm aware that this would > be global data, but it could include things like ~ based paths to user > state files. If we offer folks a neat way to store state, this would be > a strong attraction for GUI programmers to do things for FreeBSD. > > This could actually become very interesting. > > This isn't all that difficult a job, and can be done in a way that would > have no effect at all to those folks who don't want the new features, > removing any sane basis for complaint. We'd still get the insane > complaints, but I give you permission to forward those to me (great, > Chuck, open mouth, insert foot!) > > I can think of one possible complaint (beyond the non-UNIXy feel of this.) Will adding stuff to the execution image impact load time? I mean, even though that section will (likely) not be available in-core at run time, one will still have to read through it to load the executable. Perhaps if it were guaranteed to be at the end (and thus not read at all.)? Another possible complaint - "the operating system used to fit on my small disk, and now doesn't." (Of course, that always seems to be the case - and with the price of disk drives... there's little sympathy for this...) However, in a more abstract sort of mind... What I want out of FreeBSD is not a platform with icons that you can point-and-click on. But, a powerful system I can use for my development activities. I don't use the icons I have now... but, perhaps I'm just an old fogey... My point being, introduction of this may cause a dichotomy in the FreeBSD user community. Power/programming users and casual point-and-click users. I've never seen an operating system that was successful at addressing both of these at once (although Windows certainly claims to be) and, in my opinion, I want the power/programming OS, not the point-and-click one. We may be headed down a slippery-slope... I would certainly argue that any program that *required* this information to be present in an executable was flawed. - Dave Rivers - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message