garya@marvin.Solbourne.COM (Gary Aitken) (09/06/90)
The "standard" place for an application's default resources is /usr/lib/X11/app-defaults The "standard" place for all other files related to an application is /usr/lib/X11/<application_name> Considering that an application may read various other X resource files, such as: a prototyper configuration file language specific resource overrides various other "custom" configuration files to implement "standard" configurations which might be invoked from a command line option Now, considering that it's probably not a good idea to merge these files into a single .Xdefaults file which could be put in app-defaults, Doesn't it make sense for the normal application resources to reside in the same place as everything else for the application, namely /usr/lib/X11/<application_name> And while we're at it, doesn't it make sense for the application default resource file to be named .Xdefaults in that directory?
asente@adobe.com (Paul Asente) (09/07/90)
In article <1990Sep6.043946.21061@Solbourne.COM> garya@marvin.Solbourne.COM (Gary Aitken) writes: > >The "standard" place for an application's default resources >is > /usr/lib/X11/app-defaults Right so far. >The "standard" place for all other files related to an >application is > /usr/lib/X11/<application_name> Nope, it's /usr/lib/X11/<type-of-file> For example, /usr/lib/X11/uil, /usr/lib/X11/help, /usr/lib/X11/bitmaps... And within these directories, it's not application-name, it's application-class. An important distinction. -paul asente New address! asente@adobe.com ...decwrl!adobe!asente
garya@garya.Solbourne.COM (Gary Aitken) (09/14/90)
>> The "standard" place for all other files related to an >> application is > /usr/lib/X11/<application_name> > > Nope, it's /usr/lib/X11/<type-of-file> > > 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>/<format> bitmaps/<format>/<#planes> There are lots of ways we might divide up bitmaps; should we differentiate between icons and bitmaps of other sorts? Or is this <type-of-file> distinction only one level deep? Do I put my bitmaps in bitmaps/my_app/8plane bitmaps/my_app/1plane If the <type-of-file> 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 <type-of-file> structure which is only one level deep simply scatters the application all over the directory tree without accomplishing anything, since within the <type-of-file> 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 <type>. 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 <type-of-file> 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
marbru@auto-trol.UUCP (Martin Brunecky) (09/15/90)
In article <1990Sep13.201032.4285@Solbourne.COM> garya@garya.Solbourne.COM (Gary Aitken) writes: >>> The "standard" place for all other files related to an >>> application is >> /usr/lib/X11/<application_name> >> >> Nope, it's /usr/lib/X11/<type-of-file> >> >> For example, /usr/lib/X11/uil, /usr/lib/X11/help, /usr/lib/X11/bitmaps... > ...... thanx, Gary, for a thorough explanation of related issues ..... Since I was involved in a similar battle on a VMS turf, allow me to add few more observations. The approach of /<type-of-file> becomes a nightmare for a person managing the system (be it VMS, Unix or RT-11). Imagine you have to remove an application which is no more used. With the /<type-of-file>, your chances of hitting the wrong files (and destroying some other application) are pretty high, but you usually manage to remove less than 50% of the target. Next issue are potential naming conflicts. Two applications may simply choose to use the same name <type-of-file>/foo for two slightly different contents. Next issue are system upgrades, where files in /<type-of-files> may be part of the system. But you want to upgrade the system by re-loading the entire thing, only that you don't know which files to back-up to preserve across the upgrade, and which you MUST NOT since by restoring those you would negate the upgrade. No. /<type-of-file>/ is a place for very, very, very limited set of files, which is very difficult to control. I'd go so far to leave it RESERVED for the vendor supplying the system. Application specific files should always be bound within an application tree, which sometimes may even start with a vendor name: /MIT/appl_1/... The habbit of /<type-of-file> has it's roots in times of RSX-11 (and for that manner, Unix). PLEASE, don't try to force that on us today. A -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404