
I definitely agree to that. IMHO it is very important to use the toolkit's capability to custumize and internationalize the application. Every platform has it, Windows has .rc files, Gtk has style files and Apple has its functionality. If we don't make use of these facilities we wind up writing a toy (educational) API where you have 6 color constants and 3 font constants and use them blindly.
Are you sure we're talking about the same resource files here? Well, resource files are some sort of abstraction (separation of functionality and content). As such, there should be an advantage of going
On Mon, Feb 17, 2003 at 01:51:38PM +0100, Wolfgang Thaller wrote: through all this hassle, i.e. the possibility of changing resources must have benefits (internationalization, or just the fact that you don't hard-code any values in you program). In an old "Programming Windows" Petzold (3.1) I read something about "you can change the resource strings to a different language to get a foreign language version of you application".
Resources on MacOS, and, as far as I know, on Windows, have nothing to do with customization - whereas IIRC customization and "theming" are the main purpose of X11 resources and GTK style files. True, themes are the real reason of haveing these resource files. But you can (and should) use these files as normal resource files in the Windows/Aqua sense.
I was responding to Glynn Clements' statement that "User-visible text doesn't belong in the source code". For Mac OS apps, it belongs in the dialog templates (the "nib" file, a binary format editable only with Apple's Interface Builder application) and in string tables (nowadays, XML files). We don't want to end up having to draw all dialogs three times with three different (and possibly proprietary and single-platform) tools, or having to write down all user-visible text in three different file formats. ...but we would like to have a common API to look up these resources, right? I feel there is a problem.
On the other hand, it would be great to be able to store bitmaps and other data in the .EXE file's resources on Windows, and in the appropriate application wrapper on Mac OS, rather than cluttering the application directory with many files. Supporting the native way of storing data would be very nice and I would prefer that. Maybe this requires adopting one approach and build a compiler to resource formats on other platforms. Or we choose one format and use it on all platforms. This wouldn't affect native-look-and-feel but would make it harder using native backend functionality with this foreign resource files.
As far as X-style customization is concerned, are there any features that you would expect that don't come for free? No, I think theming and the like is not an issue in the sense that it would still be possible and is totally transparent for the programmer.
As a MacOS developer, I'd just expect some library to provide me with a way to say "store this data in the preferences/settings/defaults file" (which should be put in the standard location for preferences files). Do I have to use a particular resource format in order to be a "good citizen" on X11? I guess most applications still store their data in a proprietary format in a .blah file in the user's home directory. Gtk knows something about "Settings" which allows to store texts, number, colors and the like. This format is definitely proprietary. I think Gnome provides some Registry equivalent.
I would like to see this covered by the Common API, since it takes a big burden from the programmer. I could imagine a function like col <- lookupColor "automaton-state-color" black which looks up the entry "automaton-state-color" in your local resource files and returns that. If the entry is not found, black is returned as a default (and maybe this entry is created). Axel.