Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!ub!boulder!stan!garya!garya From: garya@garya.Solbourne.COM (Gary Aitken) Newsgroups: comp.windows.x Subject: Re: application resource file location Message-ID: <1990Sep13.201032.4285@Solbourne.COM> Date: 13 Sep 90 20:10:32 GMT Sender: news@Solbourne.COM Organization: Solbourne Computer, Inc. Lines: 101 >> The "standard" place for all other files related to an >> application is > /usr/lib/X11/ > > Nope, it's /usr/lib/X11/ > > For example, /usr/lib/X11/uil, /usr/lib/X11/help, /usr/lib/X11/bitmaps... I certainly hope we don't really try to standardize in this manner. It makes a lot of rather poor assumptions: 1. It assumes we can all globally decide on the types of files. There are lots of possibilities for conflicts. You mention "bitmaps" What about different kinds and formats of bitmaps? Do they all go in the same place? Or is the directory hierarchy bitmaps/<# planes>/ bitmaps//<#planes> There are lots of ways we might divide up bitmaps; should we differentiate between icons and bitmaps of other sorts? Or is this distinction only one level deep? Do I put my bitmaps in bitmaps/my_app/8plane bitmaps/my_app/1plane If the hierarchy is only one level deep, something is very wrong. Somebody has an overly simplistic view of the real world and the support real applications need. A structure which is only one level deep simply scatters the application all over the directory tree without accomplishing anything, since within the directory an application may need a subdirectory to reasonably keep track of its files. An example would be code generation templates for a prototyper. One might have /usr/lib/X11/templates but a prototyper might need C, PASCAL, Ada, C++, LISP,... files. So you end up with /usr/lib/X11/templates/proto/C /usr/lib/X11/templates/proto/PASCAL etc. The same types of issues occur for things like configuration files, and I would guess just about any other type of file you come up with. You mention /usr/lib/X11/uil, but not /usr/lib/X11/uid. None of the existing stuff I know of looks in /usr/lib/X11/uil or /usr/lib/X11/uid. The OSF Motif toolkit doesn't. 2. It assumes developers in different parts of the world, with different native languages, will come up with the same name, for the same type of file, if they need a new . 3. What are you going to do with language specific override stuff? Put it in /usr/lib/X11/german? or should it be /usr/lib/X11/deutsch? 4. It is guaranteed to break down as we build more and more complex applications. Today, maybe a of bitmaps, or templates, is sufficient for your simple applications. It is almost certain that as we learn more about what we are doing, we will develop more complex applications, and these simple categories will no longer suffice; we will want to have sub categories. At that point in time, we will have lots of "simple", previous-generation software products which will have their files in the wrong place. They will be at the level of the subdirectories, instead of in the proper, more precisely defined subdirectory. There is a fundamental difference between things which reside in directories like /usr/lib/X11/fonts, and the files we are talking about here. Things which reside in /usr/lib/X11/fonts are of interest to more than one application; these types of files DO belong in a common place. But the files we are talking about are specific to a particular application, and are of no interest to any other application. Help files, configuration files, Xdefaults files, language information, templates for generating code, bitmaps, etc. As such, they belong in a directory of private information for that application, not scattered all over the directory tree. Using your proposed method, all Makefiles should reside someplace like /usr/Makefile. But they don't, for good reason; they are specific to a particular application, and are of no use to any other. Scattering files all over the directory tree has bad practical implications. It is a nightmare for anyone trying to copy an application to another system or to a tape. Noone will ever get all the files consistently, and it will be a nightmare to update any system. Furthermore, if you get two applications from two different vendors which happen to have the same name, you will spend a lot of time straightening out the mess. Using private subdirectories for each application makes it simple; rename one application and rename its subdirectory, and change its class. I would be interested in hearing from ISV's on this issue. Are the people at Frame really going to distribute their stuff all over the directory tree? How about Visix? What about prototypers and all their support files? -- Gary Aitken Solbourne Computer Inc. ARPA: garya@Solbourne.COM Longmont, CO UUCP: !{boulder,sun}!stan!garya