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