where does fvwm get its xterm icon?
Kleene, Steven (kleenesj)
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.
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.
When startx is called, it gets this from ~/.xinitrc:
xterm -geometry 125x58+964+56 -iconic -title syrano -e ssh syrano &
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. 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.
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.
Thanks.
Nicolas George
from the applications themselves.
Regards,
--
Nicolas George
Thomas Schmitt
Kleene, Steve wrote:
> 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.
What happens if you put a file with a picture there ?
> It seems that fvwm has that image cached or built in somehow.
find /usr -name mini.xterm_48x48.xpm
> if I call "xterm &" and convert that to an icon, it appears as a
> live window screenshot, not as mini.xterm_48x48.xpm.
blindly toggled shell commands ?
I experienced such a problem with Debian 8. Without any Style "XTerm"
i got an "icon" which was indeed an active terminal with unreadble text.
I fixed this by these lines in .fvwm2rc (dunno where i learned them):
Style "XTerm" IconOverride
Style "XTerm" Icon display.xpm
The icon pixmap is probably
/usr/share/X11/fvwm2/pixmaps/display.xpm
but the same one is also in
/usr/share/pixmaps/fvwm/display.xpm
Have a nice day :)
Thomas
David Wright
> 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.
>
> 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.
Anyway, you probably want to read the man pages for fvwm and xterm as
they interact in quite a complicated manner. Use less on both and
read all the hits made by /icon.
> When startx is called, it gets this from ~/.xinitrc:
> xterm -geometry 125x58+964+56 -iconic -title syrano -e ssh syrano &
>
> 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. 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.
press (un)maximise and (un)iconify you can get some remarkable effects.
And some of the iconification options are "sloppy" for want of a
better word, as in "With this style, fvwm uses application provided
icons if the icon is changed but uses the icon provided in the
configuration file until then."
> 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.
version numbers and changelogs. I tend not to notice as I'm not a fan
of menus and iconifying, prefering everything left open on a large
area of real-estate (5x4 rather than 2x2).
Cheers,
David.
Kleene, Steven (kleenesj)
>> I can't figure out where fvwm is getting the xpm icon for an xterm.
>> ...
>> 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.
On Monday, September 17, 2018 9:41 AM, Thomas Schmitt replied:
> Maybe fvwm is not happy with the zero size.
> What happens if you put a file with a picture there ?
If I put ANY other xpm there, I still see an icon that matches
/usr/share/pixmaps/mini.xterm_48x48.xpm or a live window screenshot.
> Did you already try searches like
> find /usr -name mini.xterm_48x48.xpm
In fact I obsessively viewed all 386 xpm files on the whole system. None
other than /usr/share/pixmaps/mini.xterm_48x48.xpm matched the icon
displayed.
> Does "live window screenshot" mean that the icon is willing to execute
> blindly toggled shell commands ?
Yes. If I put the cursor in the little screenshot and type a command (echoed
in a font too small to read), it does execute there.
> The icon pixmap is probably
> /usr/share/X11/fvwm2/pixmaps/display.xpm
> but the same one is also in
> /usr/share/pixmaps/fvwm/display.xpm
I have the second of those. It gives an error about a corrupt image when I
try to display it.
On Monday, September 17, 2018 12:43 PM, David Wright replied:
> I think the intention is that you use NoIcon for no icon.
I just tried this, and it causes .xinitrc to bring up the xterms in the
background with no icon whatsoever. They show in a process list (ps), and if
I right-click on the desktop I can bring them up from the fvwm menu. That's
not a bad solution (two clicks), but I was a little happier when I had an
icon with a small name bar and no picture (one click).
Thanks to all for the suggestions.
________________________________________
From: David Wright [deb...@lionunicorn.co.uk]
Sent: Monday, September 17, 2018 12:43 PM
To: debia...@lists.debian.org
Subject: Re: where does fvwm get its xterm icon?
Zenaan Harkness
> 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.
> >> ...
> >> 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.
>
> On Monday, September 17, 2018 9:41 AM, Thomas Schmitt replied:
>
> > Maybe fvwm is not happy with the zero size.
> > What happens if you put a file with a picture there ?
>
> If I put ANY other xpm there, I still see an icon that matches
> /usr/share/pixmaps/mini.xterm_48x48.xpm or a live window screenshot.
"locked and loaded", then the effect of replacing that file on disk
will not be seen until the file gets unlocked and reloaded - logging
out of X and back in should do it (as would rebooting of course).
There ought be a more elegant "reload this icon" method rather than
logout/in - perhaps someone else knows what it is?
David Wright
restart fvwm because the decision as to which icon to use should be
being held within fvwm, not X.
BTW if you really dislike the active icon (the one that just keeps
running xterm in miniature), you should be able to disable the feature
with the xterm -ai commandline option.
Cheers,
David.
to...@tuxteam.de
Hash: SHA1
On Mon, Sep 17, 2018 at 08:44:10PM +0000, Kleene, Steven (kleenesj) wrote:
> In fact I obsessively viewed all 386 xpm files on the whole system. None
> other than /usr/share/pixmaps/mini.xterm_48x48.xpm matched the icon
> displayed.
find ... -type f -name "*.xpm" -exec md5sum {} + | sort
or something (replace md5sum with sha5sum if you fear your machine
will be hacked [1] ;^P
Identical files will be sorted next to each other.
Cheers
[1] This is to pre-empt discussions about whether md5sum is "less
secure" than say, sha512sum :-)
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlugirAACgkQBcgs9XrR2ka9DwCcDrkaZbcBgOT/T74VhifmDVWl
P/gAnjSgJUtqOpd45RIRfw+3kV9YKiCX
=4D5p
-----END PGP SIGNATURE-----
Thomas Schmitt
Kleene, Steven wrote:
> Yes. If I put the cursor in the little screenshot and type a command
> (echoed in a font too small to read), it does execute there.
Did you try the settings which helped me to get some normal icon and
to deactivate the shell as long as the window is iconized ?
Style "XTerm" IconOverride
Style "XTerm" Icon display.xpm
Iirc, it was not necessary to restart fvwm (although this is supposed to
be harmless to the current desktop population).
I remember to have issued fvwm commands for experiments via the program
FvwmCommand.
Kleene, Steven (kleenesj)
>> 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.
On Tuesday, September 18, 2018 2:15 AM, Thomas Schmitt asked:
> Did you try the settings which helped me to get some normal icon and
> to deactivate the shell as long as the window is iconized ?
>
> Style "XTerm" IconOverride
> Style "XTerm" Icon display.xpm
I just tried that and called gimp.xpm. On calling startx, I still got the
inevitable mini.xterm_48x48.xpm image. Thanks for the idea.
________________________________________
From: Thomas Schmitt [scdb...@gmx.net]
Sent: Tuesday, September 18, 2018 2:15 AM
To: debia...@lists.debian.org
Cc: Kleene, Steven (kleenesj)
Subject: Re: where does fvwm get its xterm icon?
Hi,
David Wright
I posted before.
On Mon 17 Sep 2018 at 12:05:35 (+0000), Kleene, Steven (kleenesj) wrote:
> 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.
> 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.
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:
> xterm -geometry 125x58+964+56 -iconic -title syrano -e ssh syrano &
> 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.
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.
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.
$ 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).
Cheers,
David.
Kleene, Steven (kleenesj)
>> 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.
Thanks again.
________________________________________
From: David Wright [deb...@lionunicorn.co.uk]
Sent: Wednesday, September 19, 2018 2:27 PM
To: debia...@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
Zenaan Harkness
> On Mon, Sep 17, 2018 at 08:44:10PM +0000, Kleene, Steven (kleenesj) wrote:
>
> [...]
>
> > In fact I obsessively viewed all 386 xpm files on the whole system. None
> > other than /usr/share/pixmaps/mini.xterm_48x48.xpm matched the icon
> > displayed.
>
> Not really on-topic, but perhaps helpful: next time you do a
>
> find ... -type f -name "*.xpm" -exec md5sum {} + | sort
>
> or something (replace md5sum with sha5sum if you fear your machine
> will be hacked [1] ;^P
>
> Identical files will be sorted next to each other.
>
> Cheers
>
> [1] This is to pre-empt discussions about whether md5sum is "less
> secure" than say, sha512sum :-)
No, sha5sum is definitely waaay too primitive - butterfly wings and
cosmic radiation eddies are a must for those ackshually, you know,
like, want axshul security. Like.
David Wright
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.
Nicolas George
> 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:
InitFunction, not from .xinitrc.
Regards,
--
Nicolas George
Kleene, Steven (kleenesj)
>> 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:
On Saturday, September 22, 2018 1:55 AM, Nicolas George responded:
> The real fix is even simpler: start your X11 clients from Fvwm's
> InitFunction, not from .xinitrc.
Good idea. But I (original poster) just tried it, and once again the icon
for the xterm appeared as a live screenshot instead of smplayer.xpm, which I
had defined (for testing purposes) in ~/.fvwm/config. Including "Test
(Init)" in the InitFunction didn't help. Thanks.
David Wright
the xterms placed on the correct positions, but it also has downsides
which I can avoid while xtoolwait continues to work (even with its
bug).
1) The xterms' arguments, and (for some of them) the commands they run,
are computed in the shell script that is ~/.xsession. While some of
these might be simple to perform in fvwm-ese, not all of them are,
and I'm not particularly well versed in fvwm-ese. I'm reasonably
competent in bash dialect shell-ese however.
2) I get a log of all the .xsession operations in .xsession-errors,
whereas the logging done by fvwm is almost all generated by the
Echo commands I inserted.
3) There's still a race between the xterms when started from InitFunction.
Although their placements are correct, they are mapped at their
locations in a random order instead of deterministically. This
randomises the PIDs and PTSs of their shells, which is less
convenient for seeing who's running what at a glance.
Cheers,
David.
David Wright
enough information to be able to reproduce what you are observing,
and everything I've observed at this end has tallied with the
documentation, including -iconic which I included in my later tests.
IOW the configuration commands consistently set the appropriate icon,
and it would appear correctly iconified at startup if -iconic was set,
and would (un)iconfy itself correctly after that. I think you just
have to check your files carefully, and forget about startup until you
have the correct icon interactively (un)iconifying each way.
BTW in case I didn't mention it: although fvwm/display.xpm appears
to be corrupt, fvwm is not bothered and will happily use it.
identify-im6.q16: unrecognized color `magenta4' @ warning/color.c/GetColorCompliance/1052.
identify-im6.q16: corrupt image `/usr/share/pixmaps/fvwm/display.xpm' @ error/xpm.c/ReadXPMImage/431.
Cheers,
David.
Nicolas George
> the xterms placed on the correct positions, but it also has downsides
> which I can avoid while xtoolwait continues to work (even with its
> bug).
>
> 1) The xterms' arguments, and (for some of them) the commands they run,
> are computed in the shell script that is ~/.xsession. While some of
> these might be simple to perform in fvwm-ese, not all of them are,
> and I'm not particularly well versed in fvwm-ese. I'm reasonably
> competent in bash dialect shell-ese however.
creativity, you can even call .xsession or .xinitrc itself and arrange
to have the same init code for environment and stuff but execute pre-WM
commands when it is truly the init script and post-WM commands
otherwise.
> 2) I get a log of all the .xsession operations in .xsession-errors,
> whereas the logging done by fvwm is almost all generated by the
> Echo commands I inserted.
is connected to it, and then all commands started by Fvwm will too.
> 3) There's still a race between the xterms when started from InitFunction.
> Although their placements are correct, they are mapped at their
> locations in a random order instead of deterministically. This
> randomises the PIDs and PTSs of their shells, which is less
> convenient for seeing who's running what at a glance.
from Fvwm's InitFunction will reduce concurrency and therefore make
things slightly more efficient. And I believe Fvwm is capable of doing
the wait itself, which would be even more efficient.
Also, relying on the numbers of PIDs and PTYs is really not reliable,
irregardless of how you start your xterms.
(Also, I had to wonder for a few seconds about why your xterms have
Presentation Time Stamps, but that is just because I have spent a
significant part of the week-end surrounded by multimedia jargon.)
Regards,
--
Nicolas George
David Wright
> David Wright (2018-09-22):
> > (Actually .xsession here.) That may well be, and it does work to get
> > the xterms placed on the correct positions, but it also has downsides
> > which I can avoid while xtoolwait continues to work (even with its
> > bug).
> >
> > 1) The xterms' arguments, and (for some of them) the commands they run,
> > are computed in the shell script that is ~/.xsession. While some of
> > these might be simple to perform in fvwm-ese, not all of them are,
> > and I'm not particularly well versed in fvwm-ese. I'm reasonably
> > competent in bash dialect shell-ese however.
>
> You can call a shell script from Fvwm, of course. With a little
> creativity, you can even call .xsession or .xinitrc itself and arrange
> to have the same init code for environment and stuff but execute pre-WM
> commands when it is truly the init script and post-WM commands
> otherwise.
Starting a WM and then starting a bunch of xterms is a procedure that
shellese is suited for. Setting up 20+ pieces of code to be called
from the WM for each xterm (so that WM's Waits can be placed between
the calls) is crazy. Writing a shell script, but in fvwmese, is horrible.
And writing a WM init.hook file in advance of starting the WM is just an
extra body of code to maintain.
> > 2) I get a log of all the .xsession operations in .xsession-errors,
> > whereas the logging done by fvwm is almost all generated by the
> > Echo commands I inserted.
>
> If you get Echo commands in .xsession-errors, that means Fvwm's output
> is connected to it, and then all commands started by Fvwm will too.
[fvwm][Echo]: Reading /home/david/.fvwm/init.hook Last edited 2018-09-22
[fvwm][FlocaleGetFontSet]: (-adobe-helvetica-bold-r-*-*-12-*) Missing font charsets:
ISO8859-2, ISO8859-3, ISO8859-4, ISO8859-5, KOI8-R, ISO8859-7, ISO8859-9, ISO8859-13, ISO8859-14, ISO8859-15, JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0
[fvwm][Echo]: Reading /home/david/.fvwm/post.hook Last edited 2017-04-14
[fvwm][Echo]: Reading /home/david/.fvwm/last-post.hook-wren-0 Last edited 2018-09-22
[fvwm][Echo]: none done
[fvwm][Echo]: Initialised myvar to 0
[MyButtons][FlocaleGetFontSet]: (fixed) Missing font charsets:
ISO8859-2, ISO8859-3, ISO8859-4, ISO8859-5, KOI8-R, ISO8859-7, ISO8859-9, ISO8859-13, ISO8859-14, ISO8859-15, JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0, ISO10646-1
[FvwmPager][FlocaleGetFontSet]: (-*-times-medium-r-*-*-*-80-*-*-*-*-*-*) Missing font charsets:
ISO8859-3, ISO8859-4, ISO8859-5, KOI8-R, ISO8859-7, ISO8859-9, ISO8859-13, ISO8859-14, JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0
[fvwm][Echo]: Started MyBit
Does fvwm have an equivalent of bash's set -x ?
If it were to, would .fvwm's stderr get overwhelmed by output from
every window operation and mouse-click?
> > 3) There's still a race between the xterms when started from InitFunction.
> > Although their placements are correct, they are mapped at their
> > locations in a random order instead of deterministically. This
> > randomises the PIDs and PTSs of their shells, which is less
> > convenient for seeing who's running what at a glance.
>
> You may need to enforce the order with your favorite tool, but starting
> from Fvwm's InitFunction will reduce concurrency and therefore make
> things slightly more efficient. And I believe Fvwm is capable of doing
> the wait itself, which would be even more efficient.
tests on my slowest machine (to make timing things easier) shows
that it saves 1–2 seconds in 38; just not worth the trouble.
> Also, relying on the numbers of PIDs and PTYs is really not reliable,
> irregardless of how you start your xterms.
> (Also, I had to wonder for a few seconds about why your xterms have
> Presentation Time Stamps, but that is just because I have spent a
> significant part of the week-end surrounded by multimedia jargon.)
Cheers,
David.