On Thu 20 Sep 2018 at 01:39:07 (+0000), Kleene, Steven (kleenesj) wrote: > On Mon Sep 10 08:47:39 EDT 2018, I wrote: > > >> I can't figure out where fvwm is getting the xpm icon for an xterm. > > On Wednesday, September 19, 2018 2:27 PM, David Wright replied: > > > ... If you look at the man page, it explains the > > old option -n and says "If no suitable icon is found, xterm provides a > > compiled-in pixmap" which would correspond to your reported behaviour > > as it can't find /usr/share/pixmaps/fvwm/null.xpm. > > Thanks. That could to explain how it comes up with the mini.xterm_48x48.xpm > image in /usr/share/pixmaps even when I overwrite it with something else. > > As a test, I put this line into ~/.fvwm/config: > Style xterm Icon /usr/share/pixmaps/gimp.xpm > > I also had these in ~/.xinitrc: > xterm -geometry 125x58+964+56 -iconic -title syrano -e ssh syrano & > xterm -geometry 125x58+964+56 -iconic -title numbat -e ssh numbat & > > Then I went through many cycles of exiting fvwm and calling startx. The > icons for the two xterms varied a lot from one trial to the next but were > always either the mini.xterm_48x48.xpm image, a live screenshot, or the > intended gimp.xpm. At some point I noticed that whichever xterm icon came up > first usually got gimp.xpm, while the second xterm got one of the other two > images. This seemed to be time-dependent, in other words. When I added > "sleep 1" between the two xterm calls in .xinitrc, I consistently got > gimp.xpm for both icons, as well as for any xterms I called from the command > line and iconized. > > For reasons I can't guess, this did not work with another standard xpm > (inkspace.xpm). It did work with smplayer.xpm. It did not work with my > 0-byte null.xpm or a 1-pixel red xpm that I created. The icons display in > reproducible positions on the desktop, but they are not the same positions I > saw before switching to gimp.xpm. I have a little more work to do.
That sounds like a different problem: a race between fvwm and the xterms over which order they start in. The manner in which the race affects me is that my (open) xterms get mapped all over the place instead of where I want them placed. The fix is simple except that the package required never made it past squeeze, so you'd need to visit the archives, specifically: http://archive.debian.org/debian/pool/main/x/xtoolwait/ and the program can stall occasionally, as described in https://lists.debian.org/debian-user/2017/12/msg00029.html where a fix for that bug is also given. So far, I haven't had to rebuild the package even though it is so old. Cheers, David. > ________________________________________ > From: David Wright [deb...@lionunicorn.co.uk] > Sent: Wednesday, September 19, 2018 2:27 PM > To: debian-user@lists.debian.org > Subject: Re: where does fvwm get its xterm icon? > > As you seem to be having trouble, here's a fuller answer than the one > I posted before. > > On Mon 17 Sep 2018 at 12:05:35 (+0000), Kleene, Steven (kleenesj) wrote: > > I can't figure out where fvwm is getting the xpm icon for an xterm. The > > issue started when I upgraded from Debian v7 (fvwm 1:2.5.30) to Debian v9 > > (fvwm 1:2.6.7-3). In both cases fvwm-icons was also installed. > > >From /usr/share/pixmaps/. > > > I have this in ~/.fvwm/config: > > Style "XTerm" Icon null.xpm, SloppyFocus, IconBox 200x200-1+8 > > > > where null.xpm is intended to call /usr/share/pixmaps/fvwm/null.xpm, a > > zero-byte file I created. > > Then you need to have > > Style xterm Icon fvwm/null.xpm > > or it won't be found in that subdirectory. > > That said, I would put the Icon in a directory like > /usr/local/share/fvwm/ or /home/david/.fvwm/null.xpm rather than > polluting the package's own files. > > Again, that said, a zero-length file doesn't work for me on stretch. > I haven't tried jessie or wheezy. > > > When startx is called, it gets this from ~/.xinitrc: > > I use .xsession … > > > xterm -geometry 125x58+964+56 -iconic -title syrano -e ssh syrano & > > … and I don't use -iconic so that's untested here. > > > No matter what I list in config, the xterm icon that comes up matches > > /usr/share/pixmaps/mini.xterm_48x48.xpm (an icon with a blue `T' over a red > > `X'). If I copy some other xpm on top of that and do startx again, I still > > get the original mini.xterm_48x48.xpm image. Furthermore, > > /usr/share/pixmaps/mini.xterm_48x48.xpm still shows an access time from > > weeks > > ago. It seems that fvwm has that image cached or built in somehow. > > That does seem likely. If you look at the man page, it explains the > old option -n and says "If no suitable icon is found, xterm provides a > compiled-in pixmap" which would correspond to your reported behaviour > as it can't find /usr/share/pixmaps/fvwm/null.xpm. > > > Once > > fvwm is up, if I call "xterm &" and convert that to an icon, it appears as a > > live window screenshot, not as mini.xterm_48x48.xpm. > > That's because at this point I assume you hadn't added > > Style xterm IconOverride > > to prevent it. As I wrote before, iconification is quite complex, > even before you add in fvwm's options. > > > In Debian 7, calling null.xpm gives me no xpm icon, just a title bar labeled > > "syrano". I prefer this because it's very small. > > If you just want a small icon, why not just shrink it; say: > > $ convert /usr/share/pixmaps/…whatever….xpm -resize 48x24 .fvwm/small.xpm > > Even a 1x1 icon makes a (not very useful) mark on the screen (until you > hover over it).
