Date: Wed, 28 Apr 1999 18:59:18 -0700 From: Wilfredo Sanchez <wsanchez@apple.com> To: W Gerald Hicks <wghicks@bellsouth.net> Cc: Warner Losh <imp@harmony.village.org>, John Birrell <jb@cimlogic.com.au>, hackers@freebsd.org, wghicks@wghicks.bellsouth.net Subject: Re: Adding desktop support Message-ID: <199904290159.SAA33648@scv3.apple.com> In-Reply-To: "Your message of Wed, 28 Apr 1999 11:36:14 MDT."<199904281736.LAA15179@harmony.village.org>
index | next in thread | previous in thread | raw e-mail
<fontfamily><param>Helvetica</param> You guys might want to look at what NeXT did with NeXTStep a while back; the Mach-O binary format allowed for icons and so on. In fact, /usr/bin/emacs still works that way today on Mac OS X Server (some legacy code really lasts). If you make a directory called Emacs.app, and make a symlink to /usr/bin/emacs called Emacs in that directory, the workspace will find the icon in the Mach-O executable, and display it in the viewer. Double clicking on it will launch it as an app, etc. The program itself is buggy as hell, but that mechanism still works. dyld has the API for getting to that data, and that will be release in Darwin fairly soon. What we did find eventually was that you're going to end up wanting additional resources as things get more complicated, like icons for the UI elements and so on, so we moved from one file to directory bundles which contain the executable and all associated resources in one place. For example: TextEdit.app/ TextEdit - the program binary, (n-way fat for all supported architectures) TextEdit.tiff - 48x48 Icon Resources/ more images utility programs (sort of an app-specific libexec) blah Headers/ API into the app, if any, for loadable bundles, etc. You can do this without resource forks, and it's pretty general. <flushleft>Alfred Perlstein: </flushleft></fontfamily><fixed><fontfamily><param>Ohlfs</param>| Also note that all userland programs (with the exception of dosemu) | are command line driven. Running them by clicking on them in X will | most likely do nothing. This doesn't belong in the base system, | instead it's a standard should be proposed to the GNOME, KDE and other | windowing systems people. </fontfamily></fixed><fontfamily><param>Helvetica</param> In Mac OS X Server, clicking on a Unix tool launches Terminal, and the tool runs in a Terminal window. You can do the same with xterm -exec blah, as I recall. In fact, you can script Terminal to do services, so (for example), I can navigate to a directory in the file viewer, and select a menu or command-FOO item which will do a cvs checkout/update/commit/etc. in that directory in a Terminal window. Also not hard to do in X. Thomas David Rivers:</fontfamily><fixed><fontfamily><param>Ohlfs</param> | 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. </fontfamily></fixed><fontfamily><param>Helvetica</param> Adding ease-of-use options doesn't exclude doing things The Old Way. You *can* have both. Sean Eric Fagan: </fontfamily><fixed><fontfamily><param>Ohlfs</param>| For example... Apple Computer currently has a system like what was proposed. | Actually, it's a considerably better system, since it's general-purpose, | extensible, and user-modifiable if desired, but it's along the same lines. | | They're dropping it, and going with what NeXTStEP uses, for MacOS X -- each | "application" is a directory, and has certain files in the directory. These | files include the icons (multiple ones for multiple uses, of course -- how is | the original propronent of this bloat going to handle that?), the executable, | and all sorts of other metadata. </fontfamily></fixed><fontfamily><param>Helvetica</param> Hold on there... We ain't dropping the Mac OS thing. We're using the NeXT bundle strategy in Mac OS X Server, because there we use UFS. Mac OS X will have HFS+ which gives us named attributes on any file, and we'll probably make heavy use of that, as before. Both work pretty well. I do think the NeXT thing suits BSD a lot better, because it fits the Unix model nicely, and you don't have HFS+ support (yet). Certainly you can't count on everyone using HFS+. -Fred </fontfamily> -- <bold><fixed></fixed></bold><center><fontfamily><param>Courier</param>Wilfredo Sánchez, wsanchez@apple.com </fontfamily></center><fontfamily><param>Courier</param>Apple Computer, Inc., Core Operating Systems / BSD 1 Infinite Loop, 302-4K, Cupertino, CA 95014 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the messagehelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904290159.SAA33648>