Phillip J. Eby wrote: > By now, however, the term is popularly used with GUI toolkits of all > kinds to mean essentially read-only data files that are required by a > program or library to function, but which are not directly part of the > code.
It's just occurred to me that there's another thread to the history of this term: the X window system's use of the term "resource" to mean essentially a user-configurable setting. This is probably where the usage you're referring to comes from, since Gtk and the ilk are fairly deeply rooted in X. This is really quite a different idea, although there's some overlap because X applications are typically distributed with a "resources" file containing default values for the settings, and won't work without there being some version of this file available. However, the sense we're talking about is more like the Mac one, where resources are an integral part of the program just as much as the code is, and have every right to be kept with the code. Indeed, in a classic 68K Mac application, the code literally WAS a resource. The 68K machine code was kept in the resource fork in resources of type "CODE". The data fork of an application was usually empty. -- Greg _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
