Update #1:
Many apologies for having sent the original of this message as a
reply to the wrong thread. In the future I should probably move to
the forums where it's harder to make this kind of noob mistake.

Update #2:
I now see that what I'm requesting in "tl;dnr" below isn't supported.
Instead, explicit entries of the form  "Style application-name
IconOverride, Icon desired-icon.png" *are* required for each
application. But if I'm once again wrong, any corrections/workarounds
would be welcome. I also see that you (Thomas) have been answering
this same question for close to 20 years:
http://www.fvwm.org/fvwm-ml/11051.html
https://www.fvwm.org/fvwm-ml/9863.html. My condolences and apologies
for adding to your workload.

Update #3:
Within the above limitations I think I have things under control. I
can add explicit "IconOverride" for the problematic apps and leave
everything else default. I'm still getting a crash if Fvwm is
restarted when any app is iconified, but I've always had strange
behavior (no crash though) doing that, and I need to straighten out
some Nvidia driver issues with the current install. I'll see if that
helps, and possibly build 2.7.0 to see where a null pixmap is being
sent to the X server.

Original, mis-posted message:

tl;dnr ... many thanks to all, but I'm still struggling with the
syntax. Can anyone provide me with a config line which does:

   "For all windows, search the current IconPath for a file
    <window-class-name>.png and use it if found."

and, optionally:

    "... and if not found, use the application-provided icon, or if
    none, no icon at all"

but I'd be happy with anything (except a crash ;) ) in the
"not-found" case.

(I've had some partial success with "Style ** Icon terminal.png" but
I don't want that on all windows, nor to have to add explicit "Style
FooApp Icon foo_app.png" lines for everything I use.)


On 5/11/23 12:20 PM, Klaus Ethgen wrote:
> It might be that the application brings its own icons. Search for
> _NET_WM_ICON in the xprop output.

Yes, that's what's happening. `xprop` even provides a low-res
colored-ascii-block rendition of the icon.

Thanks for clearing up this mystery.


> I myself do not use the icons as I use a custom iconize function to
> replace the icons with a small snapshot of the content. This sets the
> following styles: `WindowStyle IconOverride, Icon
> $[FVWM_USERDIR]/icon.tmp.$[w.id].png, StaysOnBottom`

That's really cool (and something that, somehow, xterms do on my
system), but I'd actually prefer a static icon (as long as it's of my
own choosing).


> So, the IconOverride here is the key.

Again as per the "tl;dnr" above, any help appreciated.


On Thu, 11 May 2023 14:38:59 -0700, Thomas Adam wrote:

> Setting ImagePath here is a little counter-intuitive.  It's a
> global command that should be set at the top of your file. See:

Thanks for the full documentation. Makes perfect sense, and I'd
already made the change at Klaus's suggestion.


> Hmm.  No.  Unless you set IconOverride, the preference is to the
> application-provided icon.

Again, thanks for clearing up what's been a mystery to me for years.
Even before my current spate of problems I've never understood why I
get one style of icon for my terminal windows (mate-terminal, KDE
konsole, etc) but a different one after a "FvwmCommand restart" (and
seemingly sometimes at random, without).


> > Q: How can I list the compiled-in default "+" ImagePath, maybe
> >    with some command in an FvwmConsole?
>
> You can't easily.

Sad, but understandable since I'm probably the first person who's
needed it in the 30 year history of Fvwm.


> Try the fvwm2 version from git.

I think the crash is only happening due to my current problems, and
only happens if I forget to un-iconify all windows before doing
"restart". (That didn't crash on my previous openSUSE versions, but
also didn't work correctly.)

If that's the case I'll probably punt and get back to what I'm
supposed to be working on instead of fighting these install teething
pains. But, yes, my next step was to build 2.x and/or 3.x from source
(openSUSE Tumbleweed doesn't provide 3.x despite being a rolling
release which claims to track the latest from all projects). If nothing
else, I was going to compile the source to add some debug output to
print ImagePath.


Reply via email to