Other BSD Window Managers; List

Hence the need for a FreeBSD specific file manager that supports ZFS. I know Chrome can be started without dbus. QT at least needs machine-id file present in some cases but not dbus itself after build. I think there will be ways around it eventually. One could even establish a QT platform upstream, and remove the requirement for dbus to build. It won't be easy but anything can be changed as long as there is the will to make it happen.
 
One could even establish a QT platform upstream, and remove the requirement for dbus to build.
And who will use that "established QT platform"? Definitely not me, I don't use QT, it is ugly and slow IMO.
The very small amout of people like qt or KDE…
The good idea is to create dbus alternative, but nobody created it until now, as far as I know.
 
And who will use that "established QT platform"? Definitely not me, I don't use QT, it is ugly and slow IMO.
The very small amout of people like qt or KDE…
The good idea is to create dbus alternative, but nobody created it until now, as far as I know.
Hahah. QT is ugly. At the moment I am using Gnome to get by but its crappy old Linux software right? Its like we get badly working versions of major DEs years later. Like you I am stuck with dbus because of certain apps but I would like not to be forever because I would like to not be tied to hand me down badly working ports of linux garbage.

Bigger picture when you need to install a single QT app but you do not want QT to pull in dbus for libxcb to build qt5 it looks like QT allows this for Darwin. A similar platform would have to established for BSDs to make building without dbus even an option from what I can tell.

I found the other day that it looked like netbsd has its own dbus alternative.

https://wiki.netbsd.org/projects/project/desktop-infrastructure/

I think its a matter of the right people fixing the upstream projects once a standard for the BSDs can be agreed upon like what is happening with sndio support popping up all over. Hence the idea for some extra threads in the same spirit as this one to collect all knowledge in one place for different components.
 
I would be tempted to actually avoid things like dbus. A long while ago I started OpenCDE as a simple desktop environment close of CDE. It was surprising how far I could get without any IPC. It made it much simpler to maintain and less stuff to break. For example, to shut down, I just called a dtadmin program which had its 'sbit' set so that it launched with admin privileges.
Sure, it makes it more limited to set permissions (i.e some users can shut down, some users cannot) but frankly things like PolicyKit are too complex and/or broken to do their with either.

I think it might be a good idea to make the DE first and then worry about IPC if / when it is needed (i.e once the project is almost complete).

Also, as for GUI toolkits, try to think of using the latest version minus one or two revisions. If the answer is no, then avoid the toolkit entirey.

For example, would anyone start a project using Qt3? No, because it is poorly maintained now and awkward to compile ourselves. Thus we can infer from that, Qt5 will be poorly maintained in only a couple of years and that we should avoid it.
Gtk+2 fairs a bit better but would be extremely hard to compile all its dependencies once it is removed from ports.

Some good contenders are Motif (still very easy to compile with almost zero dependencies outside standard X11) or wxWidgets, it has never had a complete API redesign since it was first made. Sure individual widgets have had changes over time but I have never had to rewrite a project from scratch just to use a later version of the toolkit.
 
kpedersen - What was the thing you liked best about the CDE? When I ran Solaris and had the choice, I always chose the java desktop. I just couldn't get thrilled about the CDE.
 
kpedersen - What was the thing you liked best about the CDE? When I ran Solaris and had the choice, I always chose the java desktop. I just couldn't get thrilled about the CDE.
I think for me it was consistency. I saw that CDE was almost 100% the same on every machine I used running it. It was effectively "complete".

Looking at Solaris 9 running Gnome 2 and then Solaris 10 running a very different Gnome 2 (Java Desktop), I saw that Gnome was going to keep changing. It was never going to be "finished". I personally don't like pointless change like this, especially if things like themes and workflow were going to keep on being broken.

Lo and behold after many years, CDE is still 100% the same and yet it is impossible to get Gnome 2 built on FreeBSD and all we have is a Gnome 3 in an (IMO) quite poor state, using up far too many resources and completely unusable over a remote connection.

Now for the weird bit. Alt-tab in Gnome 3 is now broken (it only tabs between windows in the same application or something stupid like that), whereas CDE never had a real alt-tab in the first place (you cannot fast toggle between two windows). It annoys me more to have something work great and then be removed than it does to not have it in the first place! :)

I think it is because I see a GUI as such a minor pointless trivial thing that it should never need to change (at the end of the day, I open up XTerm and spend much of my time in there). Unfortunately the current state of the open-source community seems to be that that no-one actually wants to do any real work, instead they just want to tinker and faff with the "easy" GUI bits and remix in new trendy (often broken) workflows.

If Wayland ever does replace X11 and breaks CDE and any chance of remote desktop, I think I will either start up OpenCDE again or be done with GUI / desktops just stick to a fullscreen XTerm clone or SSH.
 
At least that is my interest in this thread is to eventually be able to run a fully desktop with sndio, openmdns, no dbus, no consolkit, no hald, no pulseaudio and no avahi.
You can get pretty far by building everything from ports and turning all those things off in the options. The only thing that is needed eventually is dbus, because it can't be disabled in Qt5. If you want a full desktop without all that Linux stuff, Lumina is probably your best bet.
 
Call me stupid, but it feels like a lot of the ports for these WMs are outright broken. If I may, I will detail some of my experiences below:

i3wm, as simple as this WM is it surprised me the most when it appeared to be broken. I have used it extensively on other platforms, it simply won't recognize my super key, whether it's alt or meta key. Setting it manually did not improve the situation.
e16, which just straight up hangs the system.
awesome, which causes my keyboard to randomly quit working.

I only wish I knew how to configure fvwm. It looks juicy.
 
i3wm, as simple as this WM is it surprised me the most when it appeared to be broken.

i3 it's not broken, the only problem it's with this bug ( PR 208069) which failed to generate a complete i3-config. The fix it's pretty easy: copy the config from /usr/local/etc/i3 or import it from others platforms.
 
Call me stupid, but it feels like a lot of the ports for these WMs are outright broken. If I may, I will detail some of my experiences below:

i3wm, as simple as this WM is it surprised me the most when it appeared to be broken. I have used it extensively on other platforms, it simply won't recognize my super key, whether it's alt or meta key. Setting it manually did not improve the situation.
e16, which just straight up hangs the system.
awesome, which causes my keyboard to randomly quit working.

I only wish I knew how to configure fvwm. It looks juicy.

I don't want to be the serial contrarian, so don't take me wrong, but I have never experience a single issue with WMs in FreeBSD. I've used fluxbox, jwm, cwm, icewm, openbox, fvwm, xmonad, pekwm, flwm, wm2 and bspwm, as well as Lumina, LXQt, EDE and MATE as DEs (yes, trying those is part of my daily fun). Can't speak about i3, but a single sample config to manually copy doesn't look like a real bug :cool:

i3 it's not broken, the only problem it's with this bug ( PR 208069) which failed to generate a complete i3-config

To think that pkgsrc's xmonad port doesn't even install a default xmonad executable: it rather requires you to write a config in haskell importing all the wanted XMonad modules and compile your own binary with ghc(1) :beer:
 
FVWM is under GPL 2.0 according to https://github.com/fvwmorg/fvwm, which is also its download site according to the Makefile, and official repository. http://www.xwinman.org/fvwm.php also claims it is under GPL. It is so for versions 1, 2 and 3.

x11-wm/fvwm and x11-wm/fvwm2 are different versions of the same window manager. https://github.com/fvwmorg/fvwm3 is for version 3, not available in ports. x11-wm/fvwm-crystal comes from another site, and it uses FVWM as a dependency.

It is possible that the prerelease had a BSD license, because it is unspecified in https://github.com/fvwmorg/fvwm-0.91. It is also possible that FVWM uses BSD licensed components. If that's the case, when GPL takes it, it becomes that. If you like it, just use it.
Hm, a bit off topic here, but I couldn't help... Has anybody heard whether fvwm3 is expected in ports any time soon?
I'm trying now to build it manually, but... The fvwm devs encourage you to run release 3, you know. And fvwm2 is now only bug fixing.
 
You consider CDE to be the vi of desktops, i.e. never changing.
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 80286 many moons ago).
 
Hm, a bit off topic here, but I couldn't help... Has anybody heard whether fvwm3 is expected in ports any time soon?
I'm trying now to build it manually, but... The fvwm devs encourage you to run release 3, you know. And fvwm2 is now only bug fixing.
a port of Fvwm3 would be nice,
Me too,I download the source from Fvwm page and compile myself
I whish that Adam include in this version a window button style to change the button pixmap when the mouse is over them
the unoficial patchs are too old
 
a port of Fvwm3 would be nice,
Me too,I download the source from Fvwm page and compile myself
I whish that Adam include in this version a window button style to change the button pixmap when the mouse is over them
the unoficial patchs are too old
I'm sure that Thomas[1] could include such patches, however when I last looked some years ago when they were popular, there were a few problems with them which made including them problematic (such as side-stepping existing functionality). So it would have to be on a case-by-case basis. Moreover, the whole decor code will be rewritten soon, so that might be a more natural point to consider such functionality.

Thomas

[1] Adam is my surname.
 
I'm sure that Thomas[1] could include such patches, however when I last looked some years ago when they were popular, there were a few problems with them which made including them problematic (such as side-stepping existing functionality). So it would have to be on a case-by-case basis. Moreover, the whole decor code will be rewritten soon, so that might be a more natural point to consider such functionality.

Thomas

[1] Adam is my surname.
Ah, Thomas, thank you very much for your fine job :) BTW, version 3 builds and runs fine on FreeBSD.
 
Ah, Thomas, thank you very much for your fine job :) BTW, version 3 builds and runs fine on FreeBSD.
It's OK -- my parents clearly had some sense of humour when they gave me two first names -- it made my school life interesting when new teachers showed up. ;)

I'm glad it's working OK -- I am a FreeBSD user, so I have taken some steps to ensure that it builds just fine -- but if there are any issues, do please open issues on Github.

Kindly,
Thomas
 
It's OK -- my parents clearly had some sense of humour when they gave me two first names

They didn't go as far as to name you Adam? AdamAdam has a nice ring to it!

I notice the Fvwm forums have changed, perhaps I stand a chance of signing up without revising my knowledge of the Beatles! ;)

After a quick browse, I am very surprised it isn't overrun with people asking when a Wayland compositor will be built around it.
 
Hi kpedersen,

Heh, indeed. No more need for awkward knowledge such as The Beatles. We're now using Discourse which seems to be a lot easier at handling inevitable spam posts, and hence less burden on users and admins alike.

Oh, people do ask about Wayland, but the problem here is that they don't understand what they're asking for, other than it's something which they've heard about. I'm sure over time that Wayland will provide some useful feature, and it may well be that certain applications within KDE/GNOME will only work on Wayland, or have some reduced set of functionality if used with X11. Either way, until Wayland can match the performance of X11, all of this is still a glint in the eyes of people who are probably trying to move things in the right direction, but without the foresight to really make things better overall.
 
Oh, people do ask about Wayland, but the problem here is that they don't understand what they're asking for, other than it's something which they've heard about.
Ohh yess! It's new, it sounds so cool and buzzy, it must be better than boring old X11!

have some reduced set of functionality if used with X11.
Well, currently it seems rather the other way around.
I was happy that FreeBSD was not so fast with including Wayland stuff.
But with 12.2 they have started to let that stuff creep in.
Wayland's libinput library is now part of FreeBSD default xorg installation.

And thus xinput() is broken, probably more things, too.
Wayland devs don't care about the breakage they cause.
They tell users (me) to fix their libinput and send them patches.

I rather will look what needs to be added in /etc/make.conf to build without libinput and the other Wayland stuff probably creeping in the next FreeBSD releases.

Edit: Thomas, thank you very much for FVWM3 👍
 
I don't see the death of X11/Xorg happening any time soon. If Wayland is to replace X11, that's fine, but they have a duty to maintain backwards compatability since dismissing 40 years of application programming is criminal. The day a window manager such as Fvwm stops working because it's forced to be rewritten, is the day I keep something like Xorg running myself out of sheer stubborness. ;)
 
Back
Top