Resource Files (Was: Re: [GUI] More points for the technical discussion)

Axel Simon A.Simon@ukc.ac.uk
Mon, 17 Feb 2003 14:30:35 +0000


On Mon, Feb 17, 2003 at 01:51:38PM +0100, Wolfgang Thaller wrote:
> >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 
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.