wong@rtech.UUCP (J. Wong) (05/04/88)
Anyone have any hints on how to associate an icon pixmap with xterm in X11? (That is, an icon pixmap used when a window manager iconifies the xterm window.) Thanks.
barbh@hpsmtc1.HP.COM (Barbara Holden) (05/05/88)
the only way I could figure out how to do it (well, only 30 min invested) was to build my icon and then recompile the xterm source using my icon instead of term.icon.
jef@webster.UUCP (Jef Poskanzer) (05/07/88)
The following message, sent to xpert two months ago, explains one way of setting icon bitmaps in X11. - - - - - - - - - - Date: Tue, 15 Mar 88 13:44:49 PST From: jef (Jef Poskanzer) Subject: Re: How do I set an icon's pixmap? To: pacbell!sun!athena.mit.edu!xpert >If the Shell widget has an iconPixmap resource, it will be stored into the >WM_HINTS property. Both uwm and wm will acknowledge and use this (I've >verified empirically); I can't vouch for any others. Excellent. I went ahead and added a string-to-pixmap type converter, and now I can set icon pixmaps in my .Xdefaults file for *most* clients. In particular, I can set them for xterm. The issues remaining are: 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. 2) Just setting a pixmap is useful, but what would be really nice is for window managers to use the specified pixmap as a background and then add the tool's name. They do this if you let them supply their own icon pixmap, so it shouldn't be hard to get this to happen for user-supplied ones. Anyway, I've appended the diffs to lib/Xt/Converters.c to add the type converter. They also fix a minor bug in the string-to-cursor converter that prevented a user from specifying a cursor file using a full pathname. --- Jef Jef Poskanzer pacbell!sybase!jef@Sun.Com jef@lbl-rtsg.ARPA - - - - - - - - - - *** ,Converters.c Fri Feb 26 09:31:50 1988 --- Converters.c Tue Mar 15 12:42:15 1988 *************** *** 101,106 **** --- 105,111 ---- static void CvtStringToFont(); static void CvtStringToFontStruct(); static void CvtStringToInt(); + static void CvtStringToPixmap(); static void CvtStringToPixel(); *************** *** 406,411 **** --- 411,419 ---- bitmap_file_path = BITMAPDIR; } + if ( name[0] == '/' || name[0] == '.' ) + strcpy( filename, name ); + else sprintf( filename, "%s/%s", bitmap_file_path, name ); if (XReadBitmapFile( DisplayOfScreen(screen), RootWindowOfScreen(screen), filename, &width, &height, &source, &xhot, &yhot ) *************** *** 550,555 **** --- 558,620 ---- /*ARGSUSED*/ + static void CvtStringToPixmap(args, num_args, fromVal, toVal) + XrmValuePtr args; + Cardinal *num_args; + XrmValuePtr fromVal; + XrmValuePtr toVal; + { + char *name = (char *)fromVal->addr; + Screen *screen; + XrmName app_name; + XrmClass app_class; + static char* bitmap_file_path = NULL; + char filename[MAXPATHLEN]; + Pixmap pixmap; + int width, height, xhot, yhot; + + if (*num_args != 1) + XtError("String to Pixmap conversion needs screen argument"); + + screen = *((Screen **) args[0].addr); + + if (bitmap_file_path == NULL) { + XrmName xrm_name[3]; + XrmClass xrm_class[3]; + XrmRepresentation rep_type; + XrmValue value; + xrm_name[0] = XtApplicationName; + xrm_name[1] = StringToQuark( "bitmapFilePath" ); + xrm_name[2] = NULL; + xrm_class[0] = XtApplicationClass; + xrm_class[1] = StringToQuark( "BitmapFilePath" ); + xrm_class[2] = NULL; + if (XrmQGetResource( XtDefaultDB, xrm_name, xrm_class, + &rep_type, &value ) + && rep_type == StringToQuark(XtRString)) + bitmap_file_path = value.addr; + else + bitmap_file_path = BITMAPDIR; + } + + if ( name[0] == '/' || name[0] == '.' ) + strcpy( filename, name ); + else + sprintf( filename, "%s/%s", bitmap_file_path, name ); + if (XReadBitmapFile( DisplayOfScreen(screen), RootWindowOfScreen(screen), + filename, &width, &height, &pixmap, &xhot, &yhot ) + != BitmapSuccess) { + XtStringConversionWarning( name, "Pixmap" ); + pixmap = None; /* absolute fall-back for failed conversion */ + done(&pixmap, Pixmap); + return; + } + + done(&pixmap, Pixmap); + }; + + + /*ARGSUSED*/ static void CvtStringToPixel(args, num_args, fromVal, toVal) XrmValuePtr args; Cardinal *num_args; *************** *** 723,728 **** --- 788,795 ---- Add(XtQString, XtQFontStruct, CvtStringToFontStruct, screenConvertArg, XtNumber(screenConvertArg)); Add(XtQString, XtQInt, CvtStringToInt, NULL, 0); + Add(XtQString, XtQPixmap, CvtStringToPixmap, + screenConvertArg, XtNumber(screenConvertArg)); Add(XtQString, XtQPixel, CvtStringToPixel, colorConvertArgs, XtNumber(colorConvertArgs));
diamant@hpfclp.SDE.HP.COM (John Diamant) (05/08/88)
> 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