On Sat, 08 Apr 2023 13:48:40 -0700 Steven Lembark wrote:
Insall SuSE Tumbleweed on it along fvwm.
Start up a machine running SuSE tumbleweed.
Their build is fvwm 2.6.9.
Copy over my ./.fvwm/config file.
Everything works out of the box execpt for Button2 in fvwm.
I had a somewhat related problem -- now partly solved -- so am posting
in the unlikely event that it may help the original poster. But first
I'll ask some questions on what again may be a slightly related problem
which I still haven't fixed ...
I've always had strange-to-me behavior with icons in FVWM. My config
file has:
AddToFunc StartFunction
+ I ImagePath
$[HOME]/.local/share/icons/hicolor/48x48:$[HOME]/.local/share/icons/hicolor/64x64:$[HOME]/.local/share/icons/hicolor/72x72:+
From reading the documentation I've always assumed that FVWM searches
the ":"-separated paths (including the default indicated by "+") for an
appropriate image file with some "NAME" plus a supported suffix such as
".xpm", ".svg", ".png", depending on how the fvwm binary was compiled. I
recently discovered the following post, which clarified that the "NAME"
is derived from the X11 window class property:
https://fvwmforums.org/t/where-does-fvwm-find-icons-for-applications-in-windowlist/2456
In my current situation/problem (with 2.6.9, but I've had similar ones
with 2.6.7 and earlier) I'm using an audio volume control utility,
/usr/bin/pavucontrol. If I run `xprop` I get (among other things):
WM_CLASS(STRING) = "pavucontrol", "Pavucontrol"
WM_ICON_NAME(STRING) = "Volume Control"
_NET_WM_ICON_NAME(UTF8_STRING) = "Volume Control"
WM_NAME(STRING) = "Volume Control"
_NET_WM_NAME(UTF8_STRING) = "Volume Control"
So far, so good. But despite having several files named "pavucontrol"
and "Pavucontrol", with ".xpm", ".ppm", and ".png" extensions, in my
$HOME/.local/share/icons/hicolor/* directories, I'm instead getting a
different, small, volume knob icon instead when I minimize the
pavucontrol window. There are no other "*[Pp]avucontrol*" or
"*[Vv]olume*" files in either my directories or any of the system ones
I've found.
Q: Is my understanding of FVWM's ImagePath correct?
Q: How can I list the compiled-in default "+" ImagePath, maybe
with some command in an FvwmConsole?
Q: Where is the mystery small icon be coming from?
Back to the original topic ...
I have a similar situation: Laptop (10+ years old, Intel+Nvidia) which
has been running openSUSE Leap 15.1 plus FVWM 2.6.7 without any issues
(except for some ImagePath mysteries) for 3+ years. Just upgraded to
openSUSE Tumbleweed with distro-supplied FVWM 2.6.9.
Excerpts from my $HOME/.fvwm/config file:
AddToFunc "Iconify-and-Raise" "C" Iconify
+ C Raise
Mouse 0 4 A Iconify
Mouse 3 TI A Function "Iconify-and-Raise"
Mouse 3 SF A Function "Iconify-and-Raise"
Mouse 3 W M Function "Iconify-and-Raise"
Mouse 3 W MS Function windowops-or-die
This always worked with Leap/2.6.7, but on Tumbleweed+2.6.9 doing
Mouse 3 would crash FVWM with:
Process 2523 (fvwm) of user 1000 dumped core.
Stack trace of thread 2523:
#0 0x00007f1e0696190c __pthread_kill_implementation (libc.so.6 + 0x8f90c)
#1 0x00007f1e06910196 raise (libc.so.6 + 0x3e196)
#2 0x00007f1e068f8897 abort (libc.so.6 + 0x26897)
#3 0x00007f1e068f87ab __assert_fail_base.cold (libc.so.6 + 0x267ab)
#4 0x00007f1e069084b6 __assert_fail (libc.so.6 + 0x364b6)
#5 0x00007f1e078b4c03 _XAllocID (libX11.so.6 + 0x42c03)
#6 0x00007f1e07781695 XRenderCreatePicture (libXrender.so.1 + 0x5695)
#7 0x000055a9df35bb6e n/a (fvwm + 0x91b6e)
#8 0x000055a9df35c5ef n/a (fvwm + 0x925ef)
#9 0x000055a9df319586 n/a (fvwm + 0x4f586)
#10 0x000055a9df31b56d n/a (fvwm + 0x5156d)
#11 0x000055a9df2f69fa n/a (fvwm + 0x2c9fa)
#12 0x000055a9df30686b n/a (fvwm + 0x3c86b)
#13 0x000055a9df2f544c n/a (fvwm + 0x2b44c)
#14 0x000055a9df357169 n/a (fvwm + 0x8d169)
#15 0x000055a9df35706f n/a (fvwm + 0x8d06f)
#16 0x00007f1e07897dba XCheckIfEvent (libX11.so.6 + 0x25dba)
#17 0x000055a9df359e12 n/a (fvwm + 0x8fe12)
#18 0x000055a9df36cd17 n/a (fvwm + 0xa2d17)
#19 0x000055a9df306f53 n/a (fvwm + 0x3cf53)
#20 0x000055a9df331eff n/a (fvwm + 0x67eff)
#21 0x000055a9df33c230 n/a (fvwm + 0x72230)
#22 0x000055a9df33cc64 n/a (fvwm + 0x72c64)
#23 0x000055a9df33c7ae n/a (fvwm + 0x727ae)
#24 0x000055a9df2fcd8e n/a (fvwm + 0x32d8e)
#25 0x000055a9df30686b n/a (fvwm + 0x3c86b)
#26 0x000055a9df306959 n/a (fvwm + 0x3c959)
#27 0x000055a9df2dd9ea n/a (fvwm + 0x139ea)
#28 0x00007f1e068f9bb0 __libc_start_call_main (libc.so.6 + 0x27bb0)
#29 0x00007f1e068f9c79 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x27c79)
#30 0x000055a9df2df645 n/a (fvwm + 0x15645)
ELF object binary architecture: AMD x86-64
This would happen at random with shell windows, which, related to the
ImagePath problems above, are not currently showing any icon. But the
crash was 100% reproducible with `pavucontrol` (again see above). Also,
the random crashes seemed to happen more often with a quick
click-and-release of the mouse button than if done more slowly, this
being the possible relation to the original post.
After 2 days of frustration (this is my first test with Tumbleweed and
if FVWM doesn't work I can't use it because no other window manager or,
shudder, "desktop environment", is nearly as good) I finally realized
that iconifying pavucontrol with FVWM's classic Motif-style "button 4"
would *not* crash. So I changed the above bindings to:
# Mouse 3 TI A Function "Iconify-and-Raise"
Mouse 3 I A Function "Iconify-and-Raise"
Mouse 3 T A Iconify
# Mouse 3 SF A Function "Iconify-and-Raise"
Mouse 3 SF A Iconify
# Mouse 3 W M Function "Iconify-and-Raise"
Mouse 3 W M Iconify
This seems to be working for now. Apologies for the long post,
but again maybe it will provide some insights for the original
poster's problem.
