earle@SUN.COM (Greg Earle) (03/14/89)
>I believe that the current ICCCM requires all pixmaps for icons to be >of depth one. It sounds to me like that's what awm supports. Unfortunately, the same problem occurs with `xmh', which uses a depth-one icon. See clients/xmh/icon.c, it uses XCreateBitmapFromData to load 2 Pixmaps, `NoMailPixmap' and `NewMailPixmap'. In clients/xmh/toc.c, there is a check to see if there is new mail (if such a check is enabled in the resources). If so, it looks to see if the mailWaitingFlag is enabled in the resources, and if so, tries to change the icon via if (app_resources.mailWaitingFlag && toc == InitialFolder) { arglist[0].value = (XtArgVal) hasmail ? NewMailPixmap : NoMailPixmap; XtSetValues(scrn->parent, arglist, XtNumber(arglist)); } else { Under `uwm', this works, and when I iconify `xmh', I see the mailbox-with-letter -sticking-out icon (from clients/xmh/newmail.bit), like I expect. On the other hand, `awm' continues to give me it's own icon. I suspect `awm' has a bug. [ Also, `xmh' has a bug, because once the new mail has been swallowed, I would ] [ expect that the code would reset the icon to NoMailPixmap (in nomail.bit). ] [ If you examine the code immediately above the chunk above, you'll see that ] [ it appears that the only way the above code is even entered is if there's new] [ mail (there's a `if (hasmail != toc->mailpending) {' surrounding this whole ] [ chunk, a few lines up). In practice, with the Xmh*debug resource on, and a ] [ few DEBUGs thrown in to that function, that code never gets entered, because ] [ `hasmail' is set to TRUE only if the incfile exists and is non-empty, so the ] [ test above only seems to fall through when there's new mail. Or so it seems ] To summarize: I think `awm' has a bug w.r.t. icon setting. I think `xmh' has a bug w.r.t. noticing when there's no new mail, if `mailWaitingFlag' is on. If they can be confirmed, I'll gladly send in a bug report. - Greg Earle Sun Microsystems, Inc. JPL on-site Software Support earle@Sun.COM