Re: FVWM: fvwm3?
On 2/7/24 20:09, hw wrote: On Sat, 2024-02-03 at 13:53 +0100, Lucio Chiappetti wrote: I hope to be able to go on with Xorg until I live. Or use wayland and start living now :) Living in the past seldwhen is a good idea. Except when the past is better: More capable, complete, and highly evolved architectural design. Read and understand Thomas' posts. Wayland improves performance over X11's client-server model? Fine. If it wasn't possible to streamline X11 (I'm not convinced) then do the full redesign ... but include all the capabilities of the ICCCM and EWMH APIs. Even via an alternate, lower performance, internal path if necessary. As I said before, Wayland sucks. If for no other reason that it will force me to use bloated, crap window managers (excuse me: "Desktop Environments"). Either that or primitive tiling ones (talk about living in the past). But I guess I'll be able to play live, alpha-blended video as the background in a terminal window -- a nightmare, I mean utopian dream, I never knew I had or needed.
Re: FVWM: fvwm3? [on Wayland]
I'm going to document my own hatred for Wayland here, not that it will make any difference to its unstoppable adoption and the subsequent likely demise of FVWM. Note that I'm not an expert on the subject(s) nor do I have the time or inclination to become one as I'm 100% convinced that what I don't know, or any educated rebuttals to my arguments, won't change my overall conclusions. Wayland is the latest and greatest step in the destruction of the basic design concepts that are why UNIX, 50+ years after its inception, is the world's dominant operating system. It completely misses the point of separating functionality into independent and interchangeable software components. I have read the Wayland FAQ for years about why X11 needs to be replaced, and it boils down to exactly two points: 1. X11 is old. 2. It supports stippled line drawing which nobody uses any more. OK ... 1) what's wrong with that, and 2) update the API to deprecate un- and under-used functionality. Integrate the WM into the graphics server? What's next -- integrate the server into the kernel? Impossible you say, Linus would never accept that? Yeah, after years of him hating on C++ he accepted Rust because it's memory-safe. (Insist on smart pointers in C++. Problem solved.) I'll always venerate Linus for his contribution to computing -- the Herculean accomplishment of cracking Intel's insane X86 architecture to turn the toy Minix into a full-fledged virtual memory UNIX implementation -- but 30 years of being worshipped as a demigod might have gone to his head. (He recently demonstrated in one of his famous flamings, justified because the pull request in question broke the kernel, that he doesn't know how to read a stack trace.) I need FVWM, and therefor by extension X11 as has been documented here, because nothing else supports my customized desktop UI which allows me to be twice as productive as the alternatives. Not so much the visual look (an extension of MWM, perfect) but the bindings of the three mouse buttons, and most importantly the ability to iconify applications to specific positions on the desktop. All of the Gnomes/KDEs/M$Windows/Apples with their taskbars and iconboxes (in FVWM terms) require me to search by name or icon glyph through a constantly changing arrangement instead of my intuitive muscle memory moving the mouse to a known place on the screen and clicking there. I don't even have to look. Remote X11 rendering between two networked machines? I guess the Wayland designers didn't understand that concept. Either they don't care about high-end users in a professional environment, or they're only targeting the 99.9% demographic of casual users. "A GUI application? You mean a web browser connected to a cloud server, right?" I've long suspected that all of these visionaries leading us forward from the same boring old software technologies must have secret closets full of black turtleneck shirts, Levis blue jeans, and white running shoes in preparation for when they become the next Steve Jobs -- wealthy, famous, and beloved by all humanity. See GNOME 3 for a precedent. I'd like nothing more than to see a "Rebel Alliance" Linux distro that maintains X11, GTK and Qt, System V Init, config files without D-Bus, and everything else that already works (mostly) perfectly (plus any needed fixes/updates/improvements). But the huge amount of effort required (50+ highly capable and committed developers) probably means it won't ever happen. And I'm far too over-committed with my own open source projects to be able to contribute. "Retro" distributions already exist, but as Thomas astutely points out, the nail in the coffin will be when Firefox and Chromium stop working on them. You can have all the Konquerors, Vivaldis, Operas, GNOME Webs, etc. you want, but you'll eventually run into e-commerce, news, and governmental websites -- all required to function in current global society -- that fatally inform you your browser isn't supported and to come back when you're using something else. I suppose I'll hang on to FVWM/X11/etc as long as I can for my real work, probably having to add a separate/dedicated "modern" Linux box with Wayland and all the rest for online tasks. Maybe they'll keep `scp` running for the rest of my natural life so I'll at least be able to move important documents over to the "real" machine for inspection, analysis, and archiving. Sign me, Disgusted
Re: FVWM: Oddity with Mouse 2 using fvwm 2.6 & 2.7 on Suse Tumbleweed
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 .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.
Re: fvwm2 -> fvwm3 (War: FVWM: Resizing)
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 .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 renditoin 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.
Re: FVWM: Oddity with Mouse 2 using fvwm 2.6 & 2.7 on Suse Tumbleweed
On 5/10/23 2:39 AM, Klaus Ethgen wrote: > I cannot say about the other troubles but I do think, the use > inside of StrartFunction is somewhat wrong. > > I have that ImagePath set at the very begin of my .fvwm/config and it > seems to work well. > > Further more, the $HOME does not to be quoted from the documentation. > However, I do too but with ${HOME}. Thank you, Klaus. Having ImagePath globally at the beginning of .fvwm/config instead of in StartFuction makes perfect sense, and I was sure it was going to solve my problems. But it did not, nor did changing "$[HOME]" to "$HOME", "${HOME}", or even explicitly "/home/mark". I keep working on this and have lost count of how many mysteries there are. They include: I still can't find a way to examine the value of ImagePath at runtime. I finally discovered that the output of the "Echo" and other FVWM Console commands go to $HOME/.xsession-errors, but none of following gives me what I'm looking for: Echo ImagePath Echo $ImagePath Echo ${ImagePath} EchoFuncDefiniton ImagePath PrintInfo ImagePath PrintInfo ImageCache PrintInfo ImageCache verbose 1 Despite the above, I'm absolutely sure my ImagePath is being set correctly because launcher icons work. My config file has: AddToFunc BasicLaunchers + I Launcher lockscreen lkscr lock_brass_72.png \ "xscreensaver-command -lock" \ "-g -816+0" + I Launcher firefox frfox firefox.png \ firefox"-g -736+0" + I Launcher thunderbirdtbird thunderbird.png thunderbird \ "-g -656+0" + I Launcher opera opera opera.png opera \ "-g -576+0" All of those icons work, but they do not (they just show as gray rectangles) if I comment out: # ImagePath ${HOME}/.local/share/icons/hicolor/48x48:${HOME}/.local/share/icons/hicolor/64x64:${HOME}/.local/share/icons/hicolor/72x72:+ That makes sense because: $ fvwm-config --default-imagepath /usr/share/X11/fvwm2/pixmaps:/usr/share/X11/fvwm2/bitmaps:/usr/share/pixmaps:/usr/share/wallpapers and: $ find $(fvwm-config --default-imagepath | tr : ' ') $HOME/.local/share/icons -iname lock_brass_72.png find: �/usr/share/X11/fvwm2/bitmaps�: No such file or directory /usr/local/home/mark/.local/share/icons/hicolor/72x72/lock_brass_72.png $ So FVWM must be picking up my icon path and icons, right? Why do they work for launchers, but not when iconifying applications? And more ... if I create an xfce4-terminal, I get: $ xprop | fgrep CLASS WM_CLASS(STRING) = "xfce4-terminal", "Xfce4-terminal" FvwmIdent shows the same info. When I iconify it I get a very nice "terminal" icon, but where is it coming from? $ find $(fvwm-config --default-imagepath | tr : ' ') $HOME/.local/share/icons -iname \*xfce4-terminal\* find: �/usr/share/X11/fvwm2/bitmaps�: No such file or directory $ I know this has been too much information but either I'm missing something obvious or FVWM 2.x still has some bugs after all these years. Further help from anyone would be greatly appreciated.
Re: FVWM: Oddity with Mouse 2 using fvwm 2.6 & 2.7 on Suse Tumbleweed
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 0x7f1e0696190c __pthread_kill_implementation (libc.so.6 + 0x8f90c) #1 0x7f1e06910196 raise (libc.so.6 + 0x3e196) #2 0x7f1e068f8897 abort (libc.so.6 + 0x26897) #3 0x7f1e068f87ab __assert_fail_base.cold (libc.so.6 + 0x267ab) #4 0x7f1e069084b6 __assert_fail (libc.so.6 + 0x364b6) #5 0x7f1e078b4c03 _XAllocID (libX11.so.6 + 0x42c03) #6 0x7f1e07781695 XRenderCreatePicture (libXrender.so.1 + 0x5695) #7 0x55a9df35bb6e n/a (fvwm + 0x91b6e) #8 0x55a9df35c5ef n/a (fvwm + 0x925ef) #9 0x55a9df319586 n/a (fvwm + 0x4f586) #10 0x55a9df31b56d n/a (fvwm + 0x5156d) #11 0x55a9df2f69fa n/a (fvwm + 0x2c9fa) #12 0x55a9df30686b n/a (fvwm + 0x3c86b) #13 0x55a9df2f544c n/a (fvwm + 0x2b44c) #14 0x55a9df357169 n/a (fvwm + 0x8d169) #15 0x55a9df35706f n/a (fvwm + 0x8d06f) #16 0x7f1e07897dba XCheckIfEvent (libX11.so.6 + 0x25dba) #17 0x55a9df359e12 n/a (fvwm + 0x8fe12) #18 0x55a9df36cd17 n/a (fvwm + 0xa2d17) #19 0x55a9df306f53 n/a (fvwm + 0x3cf53) #20 0x55a9df331eff n/a (fvwm + 0x67eff) #21 0x55a9df33c230 n/a (fvwm + 0x72230) #22 0x55a9df33cc64 n/a (fvwm + 0x72c64) #23 0x55a9df33c7ae n/a (fvwm + 0x727ae) #24 0x55a9df2fcd8e n/a (fvwm + 0x32d8e) #25 0x55a9df30686b n/a (fvwm + 0x3c86b) #26 0x55a9df306959 n/a (fvwm + 0x3c959) #27 0x55a9df2dd9ea n/a (fvwm + 0x139ea) #28 0x7f1e068f9bb0 __libc_start_call_main (libc.so.6 + 0x27bb0) #29 0x7f1e068f9c79 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x27c79) #30 0x55a9df2df645 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