I’m sick of fighting just to get even simple automated window geometries to work consistently and sanely with #Wayland.
So I went back to the roots and discovered there is actually an #FVWM3 now!
Perfect geometries. Everything under control. Lightning fast and light. And even sound is way better directly through ALSA.
Funny how it feels amazing for my computer to work for me again, instead of me trying in vain to work with it.
#fvwm3 #fvwm #wm #archaicsoftware
Hey everyone.
I've just released fvwm3-1.1.3, the details of which you can find here:
https://github.com/fvwmorg/fvwm3/releases/tag/1.1.3
Not many features or changes in this release other than the usual bout of bug-fixes.
However, as I've bleated on about before, this release is significant in that autotools has been removed, and meson has replaced it.
This means you have to use meson or muon to build fvwm3.
The release notes mention this, but I know some will miss it. Again though, more information here:
https://github.com/fvwmorg/fvwm3/discussions/1068
Let me know if you run into any issues.
@peppe Well, #dwm is a window manager. Then there's #dwl, which is a #wayland #compositor, trying to do "functionally the same" as dwm. My point is, it has to implement a lot more stuff to do so.
My favorite window manager is #fvwm (or now #fvwm3), and as far as I know, its main developer was looking into wayland and currently doesn't have any concrete plans to work on that ... and I can perfectly understand. 
fvwm3-1.1.1 has been released!
See: https://github.com/fvwmorg/fvwm3/releases/tag/1.1.1
Note that this release represents a good nine months worth of work. In that time, there's been five new contributors (thanks to you!).
This release is notable for a few things:
1. There is a new buildsystem -- meson is replacing autotools. As from this date (2024-NOV-30), there is now a six-month timer on autools support in fvwm3. On Friday 30th May 2025, I will be removing autotools from the fvwm3 repository. meson will be the default at that point.
See: https://github.com/fvwmorg/fvwm3/discussions/1068
2. FvwmRearrange has been completely overhauled, and has a number of nifty options to control placement. Do please take a look at some of the options and examples in `man FvwmRearrange`.
3. FvwmPager has received some further updates for `is_shared` mode.
4. Moving windows and maximizing them has now gained some further options:
Moving windows can now honour window boundaries (see the `all_windows` and `both_sides` options to the `Move` command).
You can now maximize a window to honour the window below to make another window the same size: `Maximize both_sides True grow grow`.
There's also been a bunch of other changes too numerous to list here. See the release notes for more information.
Special thanks for this release has to go to Matt Jolly for all his hard work on getting meson working with fvwm.
Also, to Jaimos Skriletz for his hard work on FvwmPager, FvwmRearrange, and other areas/bug-fixes.
Let the numerous other bugs introduced with this release haunt us all!
Enjoy!
#fvwm3 #autotools #meson #muon #buildsystem
Hey all! Please note that although fvwm3-1.1.1 is close to being relesaed, there's still a few more things left to do.
Before that point, I'd like to take the opportunity to mention that as of fvwm3-1.1.1 fvwm3 is officially using meson/muon as the buildsystem of choice.
Autotools has been a tremendous help over the years. Heck, fvwm as a project started long before autotools existed.
But as technology changes, newer buildsystem alternatives have come along making better use of hardware, compilation speeds, etc.
Indeed, because of fvwm's age -- there's a tonne of custom m4 macros -- some of which are to work around issues long since gone. With autotools recently deprecating many of these, maintaining this was becoming difficult. Hence the change.
A six-month window exists once fvwm3-1.1.1 is released for downstream packagers to make the move from autotools to meson.
The `main` branch in the fvwm3 repository contains both buildsystems. Please give meson some testing!
A huge thanks goes to Kanjie (Matt Jolly) -- without whom none of this work would have been possible. Thanks, Matt!
For more specific details. please see: https://github.com/fvwmorg/fvwm3/discussions/1068
Questions? I'm here...
Still reading #ICCCM, fixing stuff in my #xcb-based #X11 code ... this time, getting "window states" correct 
https://github.com/Zirias/xmoji/commit/d244b35d1fe53226c37833949312b6ea2a0412ec
This only makes sense in presence of an ICCCM-compliant window manager, which *should* be a given, but who knows? I now deduce this by whether I'm getting a WM_STATE property or not. When my window gets one, it's only considered "closed" once this is deleted (or, changed to "Withdrawn", which e.g. #fvwm3 is doing, but then I just delete it myself in response). Otherwise, the window is considered closed as soon as the UnmapNotify arrives. I hope this is a sane approach. 
BTW @thomasadam I guess I did indeed discover a bug in #fvwm3, see screenshot:
I now set all 4 "name" properties on my window, _NET_WM_NAME and _NET_WM_ICON_NAME as utf8, WM_NAME and WM_ICON_NAME to the same strings converted to latin1. I get a correct _NET_WM_VISIBLE_NAME, but a garbled _NET_WM_ICON_VISIBLE_NAME as a result.
Just in case you're interested to look into that 
– I also might do that myself later ...
Hi all,
#fvwm3 version 1.1.0 has been released.
This release does contain fixes to bugs, as well as several different improvements to FvwmPager.
For the general release notes, please see: https://github.com/fvwmorg/fvwm3/releases/tag/1.1.0
For specific details on some of the bigger changes (especially breaking changes), see: https://github.com/fvwmorg/fvwm3/discussions/983
One thing to note for anyone who packages fvwm3 for their Linux distribution, or maintains a port of it in BSD, libXFT has now been made a core dependency, and is no longer optional. AFAICT, this seems to have been the case for most packagers, but I thought I'd mention it here.
Enjoy!
To all fans and users of #fvwm3 (there's only one of you, so...)
We've been making some changes to several things recently:
1. Fixing the syntax of commands so that the prefix of `screen` to refer to a screen (monitor) is consistent -- see GotoPage/GotoDesk/GotoDeskAndPage:
GotoDesk eDP-1 0 0
Becomes:
GotoDesk screen eDP-1 0 0
2. RandR changes:
There should now be better support for enabling/disabling monitors on-the-fly.
3. FvwmPager
This is the big one -- we've made several changes here:
- The Pager now correctly updates and reacts to monitor changes -- on, off, changed position, etc.
- With >1 monitor, FvwmPager now displays all monitors, and the area in the pager now represents clickable areas for those monitors
- `*FvwmPager: Monitor eDP-1` is still respected and should function as it always did.
We've had some interesting bugs in making this all come together and work properly.
Any/all testing is appreciated. The branch to use in fvwm3.git is `ta/fvwmpager-monitor-mode` -- please either file GH issues, or let me know of any issues.
For something more visual so you can see what's what, you'll have to suffer this video with me talking about some of the above:
https://www.youtube.com/watch?v=klczRKs-yI8
It's OK -- I'm not about to give up my $DAYJOB for a career as an "influencer". Or is that infvwmencer?
Mostly a bug-fix release for as many as I could squash.
Full details here:
https://github.com/fvwmorg/fvwm3/releases/tag/1.0.8
Enjoy!
I've just released #fvwm3 version 1.0.7
I'd like to say this is full of features and cool things. Alas, no new features, just quality-of-life fixes, and squished bugs.
Further details to be found here:
https://github.com/fvwmorg/fvwm3/releases/tag/1.0.7
Style fvwm3 StillHangingOn
