Other BSD Window Managers; List

Spectrwm is nice. I've used it, without problem, in a multi monitor setup. I have a somewhat dated page on it--I wound up preferring dwm which seemed slightly faster, but my page, which is still, I think, valid is at https://srobb.net/spectrwm.html
Yeah, I find it a really decent WM -- I tend to think of it as a lightweight XMonad without having to learn Haskell to configure it.

As it happens, I've just finished implementing spectrwm's swap workspace functionality in fvwm3 -- great inspiration. ;)
 
ThomasAdam I just did my local test, and as expected, for integrating in a port build, this is of course super easy. So, if you want to keep this way of bundling libraries, I'll add an option GO: Enable modules written in Go language with the update to 1.0.3 :)

I could even add it to 1.0.2 (fetching the patch directly from the github commit, just requires an additional autoreconf) if 1.0.3 isn't expected too soon?

BTW, I know a few megabytes don't really matter any more, but that's still an interesting proportion:
Code:
$ ls -lh work/stage/usr/local/bin/fvwm3
-r-xr-xr-x  1 felix  wheel   852K 17 Mai  18:45 work/stage/usr/local/bin/fvwm3

$ ls -lh work/stage/usr/local/bin/FvwmPrompt
-rwxr-xr-x  1 felix  wheel   3,7M 17 Mai  18:47 work/stage/usr/local/bin/FvwmPrompt

$ ls -lh /usr/local/libexec/fvwm3/1.0.2/FvwmConsole
-r-xr-xr-x  1 root  wheel    29K  7 Mai  14:30 /usr/local/libexec/fvwm3/1.0.2/FvwmConsole
(all stripped)

So, I'm unsure whether to enable the new option by default? What would users of fvwm expect?
 
Spectrwm is nice. I've used it, without problem, in a multi monitor setup. I have a somewhat dated page on it--I wound up preferring dwm which seemed slightly faster, but my page, which is still, I think, valid is at https://srobb.net/spectrwm.html
Thank you scottro, I found and read that article of yours and considered it to have been well written and very useful during my transition from Linux to FreeBSD.
I have both dwm and spectrwm installed but lately I have been using spectrwm far more than dwm.
Thanks again to you and to all the people who write the excellent Articles and Howtos for FreeBSD users.
 
Well, thank you for the kind words. It sounds like a cliche, but the thanks of you, and others who make use of the things I put up there, are what make it worthwhile to go to the effort to write them.
 
Nope, x11-wm/twm is surely the vi of wms.

I'll admit I did quite like CDE when I was running Solaris (Intel), but for FreeBSD I always return to x11-wm/twm because it is never changing (and was the first wm I encountered when running Mark Williams COHERENT on an 80E
I have discovered I'm not smart enough for KDE, Gnome and such. I tried xfce and got it so bungled up it was beyond untangling. I keep going back to twm. I like it.
 
  • Thanks
Reactions: a6h
Ah. I suspect I've fixed all of this in git, but I've not released 1.0.3 yet.
Hey, thanks a lot. Also appreciate the config file converter. It loads much faster now with the new config. The difference I've noticed is that the StartFunction stuff is on the bottom of config now. Seems to make difference.
 
Hey, thanks a lot. Also appreciate the config file converter. It loads much faster now with the new config. The difference I've noticed is that the StartFunction stuff is on the bottom of config now. Seems to make difference.
Glad to hear it! I presume you're referring to fvwm-convert-2.6? Yeah, that might end up moving some things around. However, having "StartFunction" at the bottom of your config won't break anything (it's always run at the same point after FVWM finishes reading its config file), so I suspect you have some other state which was order-dependant which has moved.

If you'd like me to check over the configs, I'd be happy to.

Kindly,
Thomas
 
Glad to hear it! I presume you're referring to fvwm-convert-2.6? Yeah, that might end up moving some things around. However, having "StartFunction" at the bottom of your config won't break anything (it's always run at the same point after FVWM finishes reading its config file), so I suspect you have some other state which was order-dependant which has moved.

If you'd like me to check over the configs, I'd be happy to.

Kindly,
Thomas
Oh, thanks a lot, very kind of you! I think now it was because I moved feh background script ~/.fehbg from .xinitrc to .fvwm/config. I have some stuff in .xinitrc, like setxkbmap command to provide keyboard layout switching method. The feh script was also there and took some time to load before the WM itself.

But could you, please, help a bit with this other little thing. I somehow couldn't find how I can make two windows stay above all the rest.
You see, FvwmPager has StaysOnTop property, and so it stays. But then I also have a clock in the opposite corner of my screen, and I want it also to stay above other windows. But StaysOnTop doesn't make THAT happen. Only Pager stays on top, the clock doesn't.
 
But could you, please, help a bit with this other little thing. I somehow couldn't find how I can make two windows stay above all the rest.
You see, FvwmPager has StaysOnTop property, and so it stays. But then I also have a clock in the opposite corner of my screen, and I want it also to stay above other windows. But StaysOnTop doesn't make THAT happen. Only Pager stays on top, the clock doesn't.

Feel free to email me your config and I'll happily advise: thomas(at)fvwm.org
 
Feel free to email me your config and I'll happily advise: thomas(at)fvwm.org
Dear Thomas, thank you again for your being so kind :) I never sent you my config because the thing works now... as often, can't tell why it didn't work some time ago, but who cares. Maybe some coma was missing somewhere or something. I've noticed, when the Style properties aren't separated by coma, fvwm refuses to recognize them ('unrecognized property!!!').
 
Dear Thomas, thank you again for your being so kind :) I never sent you my config because the thing works now... as often, can't tell why it didn't work some time ago, but who cares. Maybe some coma was missing somewhere or something. I've noticed, when the Style properties aren't separated by coma, fvwm refuses to recognize them ('unrecognized property!!!').
Hey! Not a problem, glad you've got things sorted!

Yes, it was a early design decision to let fvwm ignore errors and keep going. The consequence of that is it isn't always clear where potential errors could be. In situations where you're missing a comma, for example, that can certainly make things more awkward without giving any additional information back to the user.

It's something I'm looking to address very soon though.

Kindly,
Thomas
 
Hey! Not a problem, glad you've got things sorted!

Yes, it was a early design decision to let fvwm ignore errors and keep going. The consequence of that is it isn't always clear where potential errors could be. In situations where you're missing a comma, for example, that can certainly make things more awkward without giving any additional information back to the user.

It's something I'm looking to address very soon though.

Kindly,
Thomas
Yes, I was only able to figure that out by seeing on-screen error messages after killing X. Though later I learned about the xsession-error log, which also reports these things.
 
Back
Top