This is an error long that has not been corrected in dev-docs/INSTALL.md or fixed in ./configure. The latter is just a simple edit between Core and Optional dependencies that causes users to complain when not able to run the make command without spending time finding the solution. If the dependencies should stand as they are, then fix the ./configure process not to include libpng-dev and libxft-dev.
If those two packages are considered Optional (no need to be installed but gives an additional feature) and not installed with the Core dependencies, these are the errors when running the make command (in Arch Linux, Fedora, and MX Linux).
If libpng-dev is not installed… “no makefile found. Stop.”
libxft-dev… Makefile:438 all Error 2
NOTE: Either include them in Core or fix the ./configure.
Technically this how it worked before. Today, the distros (Arch, MX and Fedora) dependencies work differently. When libxft-dev is installed, one of the sub-dependency installs the libpng-dev. If a user plans to remove libpng-dev then libxft-dev is also removed. If libxft-dev is removed, it does not affect libpng-dev (tested on MX linux)
For your information, now when libxft-dev is included in Core (git works fine), the Core dependencies install includes also 6 of the Optional dependencies:
This is not necessarily true. Depending on the distribution the dependencies are handle differently. You can not assume that because MX has libpng-dev as a recommended/dependency for libxft-dev will be the case for every single other distribution. Sometimes this packages have different names and/or variations. For instance in the SUSE family libxft-dev is actually called libXft-devel. Also there is no libpng-dev, but there is libpng16-devel and libpng12-devel Every distro does this it’s own way. Does not matter if is rpm, deb or tgz based.
Also you need to take into consideration that FVWM is not a Linux exclusive. It’s also meant to work in BSD, and BSD handles packaging in a different way.
FvwmConsole works fine here with the latest git. Make sure you installed xterm. Also keep in mind that if you build FVWM with Golang support FvwmPrompt will be build instead of FvwmConsole.
This is not the reply I can give to the devs and end-users when they often ask what are the Core. Also, I am asking myself, why there are so few fvwm3 distro packages? Mostly test packages. Among RPM package distros only Mageia. If we look at fvwm3 among all distros, there are very few.
As you said @lgsobalvarro, “Depending on the distribution the dependencies are handled differently”. Today’s linux end-users (as well as devs) will not take the time to figure out what they are. Also, they don’t know that xterm is needed to show the manpages and FvwmConsole, python3-xdg to generate XDG menu, stalonetray for network, and the packages needed to run ./autogen.sh.
Besides INSTALL.md there must be another page in which a link is included.
The additional page online should look similar to this page I am working on for myExt… to include different distro dependencies and install instructions (still under construction).
This is a question that should be made to package maintainers.
There are non-official packages/ports for several distros, you just need to know where to look for them.
It may also have something to do with the fact that FVWM 2 is still supported, but in maintenance mode.
FVWM is an old school window manager. It has quite a learning curve too if you compare it against let’s say… OpenBox. FVWM is a product of it’s time. As far as I know one of the reasons many people stay in FVWM is because of that: it is an old school no-nonsense window manager that does not hold your hand and guides you step by step like some modern desktops/applications do. Old schools desktops and window managers requires certain previous knowledge from the user and/or willingness to learn and explore. I wouldn’t say that FVWM is meant for end-users specially if they are noobs. And if developers can’t figure out a simple make error due dependencies well… they probably are really lazy or not particularly good devs.
This is not true. You can access any man page from tty or any terminal emulator of your choice via the man command. The menu that is provided in the default config it’s simply a “commodity”.
FvwmConsole is not truly dependent on xterm neither. You can make use of any terminal emulator. All you have to do is edit the default config so FVWM invoques whatever you choose instead of xterm. Same goes for the man pages menu. Just take a look at the default config and change xterm for whatever you wish. Xterm was chosen as default due the fact is wildly available.
python3-xdg is nor a requirement, neither is stalonetray. FVWM can work perfectly well with out them. There are several ways to generate XDG menu, the default config uses python3-xdg for the same reason it uses xterm: is wildly available.
Stalonetray is not required to handle any networking. It’s simply a tray. It does nothing else. Networking is usually handled by NetworkManager, ConnMan, Wicked or whatever your system uses. NetworkManager guis usually relies on an applet to manage networking, and applets requieres a system tray, like Stalonetray.
The default config does starts Stalonetray if available in your system, but is not required, is there as a commodity.
If you take the time to check the default config you will reilase that big part of it’s porpoise is to showcase what FVWM can do and hence why it’s so well documented. It’s meant as a minimal functional config that shows how FVWM config works and as a good starting point for your own config.
Autogen only need to be run if you are using the git (developer) version. If you are using the provided releases you don’t need to. If you are using the git version then you should take into account that: it’s an unstable version, sometimes it will build (usually does), sometimes it will not (this happens rarely) and is not meant to be used by end-users.
I would argue that if you wish to use a developer version of a program, you should at least have a minimum required knowledge to know how to build it.
All improvements are welcome. You could create and submit a page for the wiki where this information is provided.
If you click on my profile icon, I am from the “old-school”. You are missing the point with your lecture.
In this thread, I am speaking about how to get Fvwm3 installed with ease by the end-users without them spending too much time figuring out technical matters. To create Fvwm configs and expand its functions is a completely different story.
Regarding documentation, Fvwm is based on man-pages. For your information, when Arch Linux was created in 2002, Judd Vinet did not include man-pages because nobody reads them besides the developers. Instead, in 2004 I invented the Arch Linux Wiki that became the base for the well documented Arch Wiki which is maintained by the end-users.
If you mean this page. It is a static Github page. It is not a wiki as per the definition that is developed collaboratively by a community of users, allowing users to add and edit content. This is why the page is not completed and not updated. But first, Fvwm3 needs one page on how to install it on different distros and by the end-users. I can provide this information.
Well in that case I would suggest you use something like OBS and build the packages for all those distros yourself. All they would have to figure out themselves would be how to add a repo and install the package.
I think that keeping a list of dependencies for every (major) distro is a fools errand . No one does that. But you are welcome to try
Judd Vinet… that’s a name I haven’t heard in a while.
I used to use Arch Linux back then too. And I do recall that man-pages where available. Maybe initially the package was not part of core but they where there.
That does not mean that the Arch Wiki wasn’t useful it was, specially when the man-pages left something out.
Last time I check I can clone the wiki, modify it’s content and submit a patch, and it’s all made in Markdown. But yes… some people may think this method is inconvenient. I suppose you could start a proper wiki yourself, or have a chat with the current maintainers to transition from the current system to another one.
Not really. I would argue it has to do with the fact there are too few people working at FVWM, and most end-users simply relay in man-pages or have been using the same config for the last 20 years or so. They don’t really care about completing or updating portions of the wiki. I think there are other things that take priority over a couple of potential users not being able to figure out their build fails due dependencies.
Keep in mind that the wiki is meant to be version agnostic, that’s to say that the information provided in there at the moment works with FVWM2 and FVWM3. This may change in the future depending in how FVWM3 evolves. There is a proposal that has been disused to, at least, clean up the current syntax and get rid of duplicated commands.
As I said, you can clone this repo, create the page, provide the information and link it to the Wiki, then submit the patch. Or as I said before, have a chat with the current maintainers and propose a different way to handle the Wiki.
Only samples of different package build distros (debian, arch, gentoo, freebsd, etc.) But there is a better solution because the development packages (*-dev) are only there to build the binary files. The running packages (libevent, libx11, libxrandr, libxt, and libxft) are already installed by all distros.
Ask distros to create fvwm3 package.
Until there is no package, provide the end-users an fvwm3-flatpak.
You are missing the point with your lecture.
