I added a second commit to remove some old Fortran module files, a couple .bat files, and some Qt Creator artifacts that got left in the source tree at one point. I'll squash those two commits to make it a little cleaner.

There is two python scripts in the tree that probably don't need to be there and could be moved to the tools directory. I'll wait for some feedback from @jsherer to see where he wants to put those. But that can be done as part of starting to sort the classes out into folders.

We need to get the source tree so it's more understandable. There's some of the header files that have a .h extension, and others that are .hpp. Those should be standardized to use one or the other. I prefer just .h since that is used for both C and C++ and it's just a matter of personal preference as to which you want to use. In this case we don't have any C code so either could be used.

A general cleanup and organizing of the tree is going to touch just about every file. But it needs to be done because at present it's like a bunch of animals got loose and started scattering files all over the place. I realize that most of this came from WSJT-x, but still. Do it one step at a time and get everything sorted out. Then we can tackle that mainwindow monster before it gets bigger and grows two heads.

We need to check the files in docker/ and see if they still work.

Yeah, I would not recommend using Qt6.4. Qt versions are not portable. The Qt Group has deprecated a lot of stuff since 6.4 and it will likely inject bugs you haven't found yet since the current code base is coded for 6.9 or newer. Just because it builds don't mean everything works as expected. Without looking in the official CMake build system, I don't remember what I set the minimum Qt version at, but it most definitely won't build with CMake on 6.4 due to deprecations in Qt.

So docker should either be brought up-to-date to use Qt6.9.3, or eliminate it to prevent broken builds that might get distributed with it somehow.

Oh yeah, I remember now at least one of the deprecations I fixed for SetTimeSpec. So you'll likely end up with either timing, or timers that don't work properly on 6.4.

I'll merge this for now, but this is just a start at cleaning up the source tree.

One additional comment:
I set the min Qt version at 6.5 for CMake some time back, and that was because of linux won't build on 6.4 with the official build system. That was just a hack patch for linux. But that needs to be set to 6.9 because even 6.8 breaks a Windows build. On MacOS, 6.8 does not support the FFmpeg audio back end (which is why it don't work on Windows either). So that will be an upcoming fix.

6.9.3 is the officially supported LTS release for the Qt 6.x-series. And while I expect to be able to stay on 6.9.3 for at least two years, I have been looking at some code ports that are compatible with 6.9.3, but become necessary for 6.10.

Yep, totally makes sense @Chris-AC9KH I had a Qt 6.4 system that I wanted to try the latest on. Works fine on linux with a few minor modifications using the docker build.

Yeah, I don't know what's different with docker, but after the code was ported to 6.9 Joe reported it won't build anymore with Qt6.4. Qt6.4 is no longer supported by the Qt Group. Seems to me they had a 6.5.3 LTS release, they skipped over 6.6, had a 6.7 LTS, skipped over 6.8 and 6.9 is their latest LTS.

This is not a problem at all with .AppImage, which is the only thing we can officially support on linux. I use the linux build scripts to build a test version on linux, takes less than 10 minutes and doesn't rely on distro-packaged Qt. The official Qt6.9.3 libs for linux have FFmpeg audio, wayland support, and scalable vector graphics so Qt elements display correctly on the more modern linux desktops.