Axel Simon wrote:
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.
Xt applications don't read the resource database explicitly. The application creates a widget of a particular class with a specific name. Xt retrieves all of the widget's properties from the resource database automatically. The key point is that the details of the UI's appearance are separated from the application logic. The program just creates the widget and notes its "handle". Motif takes this approach a step further via the MRM library. This allows an entire UI hierarchy to be loaded from a UID file with a couple of function calls. The application can then retrieve widget handles by name or index. This allows the UI to be constructed using an interface builder, possibly by someone without programming skills.
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).
This has some similarities to XtGetApplicationResources(). However,
all X resources have both a name and a class; e.g. you might have
several font resources, each with a distinct name but all with the
class "Font". To retrieve a value, you specify both the name and the
class (as well as the type, size, result location and a default
value).
Also, Xt doesn't have type-specific get/set functions; the type is
passed in as argument, and the set of types is extensible. A
polymorphic function might be preferable.
--
Glynn Clements