I have just released gtk-fortran 4.1, based on GTK 4.4.0 and GLib 2.70.0, and generated with Fedora 35.
Concerning gtk-fortran itself, under the hood the main change is that each interface now uses the import :: statement instead of use, intrinsic :: iso_c_binding, only: (although anecdotal, the overall size gain is 6% on the 9822 interfaces).
Since gtk-fortran 4.0, new How-to were added in the tutorials section. A new gtk-fortran-extra repository was created with more examples under MIT license demonstrating applications that can be built either with or without their GUI (see that post). And a repository gtkzero_fpm demonstrates how fpm can build a gtk-fortran project (see that post).
Concerning GTK 4.4, the novelties are listed in the NEWS file of the project, and main changes are presented in the GTK blog. The new OpenGL renderer has been improved. And the GTK Inspector is now enabled by default: although very useful, you will find few documentation about that application. See that page: you can launch the Inspector with CTRL+SHIFT+D, and inspect the widgets of your GTK application. You can even edit the values of their parameters on the fly. See also that demo: GTK - GtkInspector Part-02 - YouTube
gtk-fortran 4.1 was tested under Fedora 35, Ubuntu 20.10, FreeBSD 13.0 and MSYS2/Windows 10 with GFortran. And also with ifort 2021.4.0 under Ubuntu 20.10. Known issues are here. If you have other compilers, I am interested by the warnings they print and by the problems encountered when running the examples. See the installation instructions.
I prefer to install such big dependencies using Conda. I see gtk2 and gtk3 Conda packages, but not gtk4. Is not not packaged yet?
Another option I like is spack, I can see the gtkmm and gtkplus packages, not sure which one is needed.
I was thinking we can experiment with gtk-fortran for the GUI for fpm, see how it works compared to the Tcl/Tk. But I would like to install all dependencies using Conda, to be uniform on all platforms.
Concerning the fpm GUI, before duplicating the community effort, we should inquire if there is a real advantage in using GTK rather than Tk, as @Arjen 's tool has the great advantage of already existing:
concerning the GUI itself, it needs only classical widgets like buttons, menus, combo box, text view, etc. I don’t think GTK will bring something more compared to Tk.
Except it could be developed in Fortran, a more familiar language here.
Concerning the packaging and distribution of the tool, I am not familiar neither with conda nor Tcl/Tk, and therefore I have no opinion.
But I can say that in the present state, gtk-fortran is running in Windows via MSYS2/MINGW64, so not natively.
Probably a first step would be to try to test gtk-fortran on a machine where gtk4 was installed only with Conda. And for me it would be a useful information in itself.
Aside: for the FPM GUI, PyQt/PySide2 is also an option (but of course, then you are writing it in Python. But if you are already using conda…). Tk apps always seem very old fashioned looking to me. I’ve never used gtk-fortran. But, speaking as someone who wrote GUIs in Fortran for years… I don’t think it’s a good idea to write GUIs in Fortran.
gvsbuild
This method provides scripts to build the GTK stack from source and outputs libraries and tools that can be consumed by Visual Studio or Meson based projects.
In fact, I think Windows applications generally embed their own GTK dlls in their directory. There is of course GIMP: historically GTK+ was developed for GIMP in the 90’s (GTK = GIMP ToolKit). I remember at the beginning of the gtk-fortran project having successfully build the examples using the dll in the GIMP directory… But my Windows skills have declined and it seems now a strange world for me.
Remark: GTK has migrated to Meson a few years ago.
Another interesting alternative for a fpm GUI would be Java. Let me explain my experience:
I am teaching the basics of statistical physics using models like Ising model, random walk, percolation, etc., using Java programs with a GUI to show graphically the results. The GUI is made with the Swing toolkit which is a part of the Java language (there is now also the more modern JavaFx, but a few years ago Oracle decided to put it in a separate package, which made the overall installation more complex).
Before Covid, my idea was to migrate toward C and GTK 3, hopping some speed increase in the computations (in fact I was surprised to realize that modern Java is nearly as fast as C for that kind of computation…) But with the confinements and distant teaching, I was really happy with Java: most of my students had either a Windows machine (~80%), or macOS (~20%), with just a few Linux. Java is already installed on most machines, and if it is not it’s very easy to install. Java saved my distant teachings!
Finally, Java is very popular (3d place in the October TIOBE index), and perennial (26 years old).
When you need a multi-platform GUI program easy to install, a Java (Swing) GUI must be considered.
Java is popular, but it doesn’t seem to interoperate that well with the rest of the ecosystem, and it has a huge runtime that you have to carry around. The Gtk or Qt approach allows to create a small binary (possibly with shipping some shared libraries with it, but users don’t have to know or care), that just works on Windows, macOS and Linux, and users just download and install.
of already existing: