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>
next in thread | previous in thread | raw e-mail | index | archive | help
<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=20 | not a platform with icons that you can point-and-click on. But, a = powerful=20 | system I can use for my development activities. I don't use the icons = I=20 | have now... but, perhaps I'm just an old fogey... My point being,=20 | introduction of this may cause a dichotomy in the FreeBSD user = community. =20 | Power/programming users and casual point-and-click users. I've = never seen=20 | an operating system that was successful at addressing both of these at=20= | once (although Windows certainly claims to be) and, in my opinion, I = want=20 | the power/programming OS, not the point-and-click one. We may be = headed=20 | 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. |=20 | 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>Wilf= redo S=E1nchez, 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 message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904290159.SAA33648>