Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!decwrl!hplabs!hpda!hp-sde!hpfcdc!hpfclp!diamant
From: diamant@hpfclp.SDE.HP.COM (John Diamant)
Newsgroups: comp.windows.x
Subject: Re: Icons & Xterm (X11)
Message-ID: <9740019@hpfclp.SDE.HP.COM>
Date: 8 May 88 03:35:18 GMT
References: <2044@rtech.UUCP>
Organization: HP SDE, Fort Collins, CO
Lines: 51

> 1) If a client specifies its own icon pixmap, for example xload, xclock,
> xlogo, then any user-specified iconPixmap resource is apparently ignored.
> I've tried the obvious "xclock*iconPixmap: bitmapfilename", and a bunch of
> variations, and I can't get it to listen to me.  This is probably just
> a matter of me not understanding the defaulting precedences for resources.

This is probably due to the default priority the Toolkit uses.  Typically
a program will pass in initial values for a widget via the widget arguments
in the call to XtCreateWidget.  Unfortunately, once this is done, there
is no way to override it with user specified defaults.  Generally, this
isn't desirable.  What most programmers want to do is specify defaults
not hard-coded values.  For resources that are easily specified in a
defaults file, the way to do this is in the app-defaults file, rather
than in the call to XtCreateWidget().  In this way, the arguments will
be overridable by the user's resource database (.Xdefaults, xrdb, -xrm
option, whatever).  Programmers, take note -- if you hard code your
values in with arguments to XtCreateWidget, they aren't overridable.
Anyway, for many resources, the app-defaults file will solve the
problem.  There are two difficulties with it.  First, if the file
somehow doesn't get installed, then the program will behave strangely.
Second, some resources such as bitmaps are both inefficient and
clumsy to specify in app-defaults (requires a separate bitmap file
available at run time and forces the program to spend time reading the
file on startup).

It is true that there is a way to do this correctly in the program,
but it requires the widget user to look up the resources himself and
set the widget instance up himself (which is ugly to impose on
programmers who aren't widget writers).

There is a solution to this problem, I believe, with a modification
to the Toolkit.  If the Arg type were modified to contain a flag
(say XtDefault or XtOverride) specifying whether the argument were
supposed to override a default in the resource database or not, then
the code inside XtCreateWidget could check the flag when it was
setting the widgets resources.  XtSetArg could either be modified to
take an extra argument (an incompatible change with the current Toolkit) or
it could be made to assume a value of the flag (I would propose XtDefault
rather than XtOverride).  Then an addition function could be provide
(say XtSetOverrideArg) to take care of the case where the programmer
really wants to prevent the argument from being overridden.

I would still encourage programmers from using app-defaults for most
default values as it makes it easier for users to look up the default
values in order to change them, but I think this change to the Toolkit
would substantially improve the flexibility of typical X Toolkit
programs.

John Diamant
Software Development Environments
Hewlett-Packard Co.		ARPA Internet: diamant@hpfclp.sde.hp.com
Fort Collins, CO		UUCP:  {hplabs,hpfcla}!hpfclp!diamant