Other BSD Window Managers; List

unfortunately both dbus and consolekit are security problems from linux - they take massive efforts to "shake down" if you expect that "any old app" would be blocked from abusing them - and when you install something like gnome3 or kde you get countless apps who's origin are not fully checked up on and all have both dbus and networking access through (gkt?).

there is rumor wayland "compositing" isn't needed since XDamage is, in the newer X11, again working. infact there is some question how it became "not working" in certain past releases.
 
I'm porting "Motif 2.5.0 w/panner" Motif 2.2.0 (pre-font hacks, the "original" open release) as I speak, and i have a multi-host desktop panner and menus!


QUESTION: when i finish "a bsd only make", how do i package it (the least painful way) for (ports)?
 
Last edited:
Does the panner in this mwm allow for virtual desktops? A while back I used a tool called vdesk to move the windows around to fake a virtual desktop.

I am a little bit weary of CDE moving to autotools (If I had to choose some complex build system over pure Makefiles, then CMake would be my main choice). Is this related?
 
Does the panner in this mwm allow for virtual desktops? A while back I used a tool called vdesk to move the windows around to fake a virtual desktop.

I am a little bit weary of CDE moving to autotools (If I had to choose some complex build system over pure Makefiles, then CMake would be my main choice). Is this related?
OpenMotif 2.x removed Motif "a kind of hardware virtual screen support" (a screen behind the screen), which stopped the original panner. The new panner pans only by requesting windows move.

I agree about autotools. As for CDE, WSM isn't default built, that'd require CDE be installed to build. This release doesn't help or prevent that I believe.
 
Last edited:
Had i know how long it'd take I would have worked on porting android or something "newer" ? :) But i like using it - there are times when "stable and no lib depends, but not twm" is my need.

It is non-linx, purely freeBSD 12.2 adm64, has new Zoom panner.

It builds using simple Makefiles OR using imake + cf system (with quats) (yes, imake build is working with Xorg and clang). Panner now zooms in/out and more stable (be cooler if it was for all X, not tied into motif - isn't heavily).
 
Last edited:
Has anybody heard whether fvwm3 is expected in ports any time soon?
The key is, someone has to create and sumbit it ;) I'm on it now, will submit after giving it a bit of polish I guess. We'll see whether it will be accepted :)

But I already have a first problem running it, can't get EdgeScroll to work any more :(
 
What do you mean you say you can't get EdgeScroll to work any more?
Tried a lot in FvwmConsole now starting with simple things like
Code:
EdgeScroll 100 100
EdgeResistance 100
EdgeThickness 1
but also trying the new styles for resistance when moving a window, trying no resistance, trying to set scrolling to only 50, and it almost works as expected, except I have to drag a window for scrolling to work. Without dragging a window, nothing happens bouncing the edge of the screen. I'm currently running 1.0.2 from the tarball released on github.

Meanwhile, the port makes good progress here: https://github.com/Zirias/zfbsd-ports/tree/master/new/x11-wm/fvwm3

Don't use it yet, have to work on the pkg-plist to honor all the build options (it's only correct with all options enabled right now).
 
Tried a lot in FvwmConsole now starting with simple things like
Code:
EdgeScroll 100 100
EdgeResistance 100
EdgeThickness 1
but also trying the new styles for resistance when moving a window, trying no resistance, trying to set scrolling to only 50, and it almost works as expected, except I have to drag a window for scrolling to work. Without dragging a window, nothing happens bouncing the edge of the screen. I'm currently running 1.0.2 from the tarball released on github.
Ah. I suspect I've fixed all of this in git, but I've not released 1.0.3 yet.
 
And it landed: x11-wm/fvwm3. And of course I'll submit a port update as soon as 1.0.3 is out :)

The one thing that's missing is FvwmPrompt, written in Go. Unfortunately, I have no experience whatsoever with Go, and already fetching the modules via a proxy failed, so I guess I'll ask upstream for help with that… so far, FvwmConsole and FvwmCommand do the same job, therefore not a huge issue :)
 
And it landed: x11-wm/fvwm3. And of course I'll submit a port update as soon as 1.0.3 is out :)

The one thing that's missing is FvwmPrompt, written in Go. Unfortunately, I have no experience whatsoever with Go, and already fetching the modules via a proxy failed, so I guess I'll ask upstream for help with that… so far, FvwmConsole and FvwmCommand do the same job, therefore not a huge issue :)
I could make this a lot easier by using Go's vendor modules, that way I'm bundling known version which work, in the repository, which would make packaging those a non-issue.

Would that work for you?

Thomas
 
I could make this a lot easier by using Go's vendor modules, that way I'm bundling known version which work, in the repository, which would make packaging those a non-issue.
Unfortunately, I don't really understand this. As I said, I have zero experience with Go ;)

I had a look at the infrastructure present in the FreeBSD ports tree, and it seems it can make use of "Go modules" in an easy way:
Code:
# GO_MODULE
#    The name of the module as specified by "module" directive in go.mod.
#    In most cases, this is the only requred variable for ports that
#    use Go modules.

Using this, it tries to fetch modules via https://proxy.golang.org – this URL is overridable as well. The problem I was facing was: putting github.com/fvwmorg/FvwmPrompt there, fetching via the proxy failed. Maybe it doesn't work because this doesn't correctly reflect the path within the repository? But this is just a guess…

The key issue is: With FreeBSD ports, the "fetch" phase is clearly separated from the "build" phase and must happen in advance. Probably to ensure completely reproducible builds. Also, network access must not be required during "build"…

Thanks for your answer!

edit: It's also unclear to me how that would work in a situation, where the go.mod file is updated in master, but you're trying to build from a released tarball. I guess I need to learn more about the Go ecosystem :eek:
 
I look forward to having a proper play with Fvwm 3 :)

It seems strange to me to randomly pull in Golang for a small module. Were the current languages in Fvwm (Perl and C) not enough for a certain task?
 
I look forward to having a proper play with Fvwm 3 :)

It seems strange to me to randomly pull in Golang for a small module. Were the current languages in Fvwm (Perl and C) not enough for a certain task?

That's why it's optional at compile time for now.

I'm either going to kick out FvwmPrompt and form something like "FvwmGoodies" which includes all these external programs, or I'll make more of an effort in increasing Go's use. The original aim of this was to see users' reactions to having Go there in the first place, as I had (am?) intending on increasing Go's use in Fvwm3.

So far, the response has been lacklustre.
 
Unfortunately, I don't really understand this. As I said, I have zero experience with Go ;)

I had a look at the infrastructure present in the FreeBSD ports tree, and it seems it can make use of "Go modules" in an easy way:
Code:
# GO_MODULE
#    The name of the module as specified by "module" directive in go.mod.
#    In most cases, this is the only requred variable for ports that
#    use Go modules.

Using this, it tries to fetch modules via https://proxy.golang.org – this URL is overridable as well. The problem I was facing was: putting github.com/fvwmorg/FvwmPrompt there, fetching via the proxy failed. Maybe it doesn't work because this doesn't correctly reflect the path within the repository? But this is just a guess…

The key issue is: With FreeBSD ports, the "fetch" phase is clearly separated from the "build" phase and must happen in advance. Probably to ensure completely reproducible builds. Also, network access must not be required during "build"…

Thanks for your answer!

edit: It's also unclear to me how that would work in a situation, where the go.mod file is updated in master, but you're trying to build from a released tarball. I guess I need to learn more about the Go ecosystem :eek:

Yes, it's confusing. I wouldn't worry about it for now -- it's purely optional at this point. But the following commit might make this easier in terms of reducing the amount of scope (I've heard some packagers in Linux distros needing to package all dependencies first which seems... tiresome to me):

 
So far, the response has been lacklustre.
When packaging/porting, my aim is to provide all the features offered upstream, so I try to get this working ;)

If you'd ask me for my opionion though… although I see how C often needs a lot more code than one might consider sane, it's also perfectly portable and sane handling of dependencies is a solved problem on most target platforms. I like C very much ;)

But the following commit might make this easier in terms of reducing the amount of scope
I'll have to take a look. But the whole idea to integrate all the dependencies into your own repo seems horrific to me. If they are meant for "static linking", something like this "go modules" facility looks saner. Well, maybe I misunderstand how it's supposed to work.
 
When packaging/porting, my aim is to provide all the features offered upstream, so I try to get this working ;)

If you'd ask me for my opionion though… although I see how C often needs a lot more code than one might consider sane, it's also perfectly portable and sane handling of dependencies is a solved problem on most target platforms. I like C very much ;)

Oh, me too. However, there's a few points here which relate to my wider goal:

* The internal `libfvwm3.la` library isn't flexible, and isn't exposed externally -- requiring modules of any language which can implement C APIs (either directly or via FFI if the language supports it) to write modules which have to be included in fvwm directly. Not ideal.

* Most operations which consumers of third-party modules need are really event-based (a la FvwmEvent). Currently, perllib (again, embedded in fvwm's repository) exposes most of the fvwm internals, but isn't very optimal. Taking this approach further, we can use abstractions using JSON. This is what FvwmMFL provides.

* Golang (or any other language which isn't C) is very important for fvwm's future. C is a brilliant language, but not something module writers for extending fvwm's functionality are likely to want to use. I believe FvwmMFL's exposure permits any language which can consume JSON in some way the freedom to write most modules, and implement any other design patterns around it (such as Observable, for monitoring window changes).

* I am a keen Gopher and Rustacean, and as such, if I believe one or both of those languages could enhance fvwm in some way, I won't hesitate to use them.

* Having a fvwm C-core with peripheral modules in $SOME_LANGUAGE is where fvwm has been heading in for decades.

All of this justification though is tedium when it's just me who's actively working on any of this -- so most of the decisions thus far are my own, where I am desperately trying to balance my own wishes with future-proofing.
allow do
I'll have to take a look. But the whole idea to integrate all the dependencies into your own repo seems horrific to me. If they are meant for "static linking", something like this "go modules" facility looks saner. Well, maybe I misunderstand how it's supposed to work.

See above -- many languages now offer a vendor/ directory to place known working versions of dependencies. This ins't "horrific", it's a guarantee of what works, and stops the madness of many a headache for packagers -- it's one or two steps removed from things like Flatpack. It not only helps packagers, but having those known dependencies means they can see what's needed, and if not packaged generically, means there's no necessarily additional work for them, as the program will build against those libraries just fine.
 
ThomasAdam, I have two thoughts on that (on different aspects):
  1. So far, I never got the idea that the "fvwm modules" were somehow meant to be implemented by users (or generically outside the project itself). If that's the goal, it definitely makes sense to offer some abstract API not tied to a specific language. I think JSON on a local socket is a good choice for that purpose. With that in mind, I'm not sure FvwmPrompt must be part of the main build at all? Maybe it would make more sense if it had its own build? If all it uses is this JSON API, there won't be any library dependency, right?
  2. I still think literally including all dependencies in your own repository is a horrific solution. Sure, there's always the conflict between reuse of (shared) libraries and reproducible builds. But then, if you go the route to bundle libraries, some package management for that is IMHO the better approach. There are a lot of tools trying to provide that (like npm, yarn, nuget, I just assume these go-modules are meant to solve the same thing, not sure because Go is entirely new to me). Often, there are problems integrating these in a sane distribution packaging mechanism, but it would be better to solve these problems then. I've had a quick look at some Go ports in the FreeBSD tree, and some look very simple just using a go modules proxy to fetch all dependencies (for example https://cgit.freebsd.org/ports/tree/devel/gogs/Makefile), so it seems to work fine.
edit: BTW, don't get me wrong, I'm pretty sure having all libs bundled in the repo should be fairly easy for packaging, and I will have a look for sure! My concerns are more about the upstream side, well, it will be your burden to maintain that whole stuff, right? ;)
 
Partial list of BSD style wm's:
........................
Lightest:
x11-wm/antiwm - C - fullscreen
x11-wm/bspwm - tiling
x11-wm/cwm - C - floating
x11-wm/ctwm - twm variant
x11-wm/dwm - C - requires C compiling to configure
x11-wm/tinywm
x11-wm/twm - C Xlib - reparenting
x11-wm/vtwm - twm variant

Light:
x11-wm/blackbox - C++ - floating
x11-wm/i3 - tiling
x11-wm/jwm - C - floating
x11-wm/qtile - python - tiling

Heavy:
x11-wm/enlightenment, x11-wm/e16 - C
x11-wm/fluxbox - C++ - floating

Unspecified:
x11-wm/compton
x11-wm/euclid-wm
x11-wm/golem
x11-wm/hs-xmonad - haskell - heavy dependencies
x11-wm/mcwm

(above contain BSD, ISC, MIT and similar licenses)

9wm derivatives (also use 9wm derived licenses):
x11-wm/aewm, x11-wm/evilwm, x11-wm/w9wm
Hi,

My WM of choice
It probably belongs in the "Lightest" section
x11-wm/spectrwm Tiling, written in C, ISC license.
Thanks
 
Back
Top