What should I use for desktop GUI programming? I am thinking of using Tcl/Tk due to its relative simplicity, acceptable license, and cross-platform availability.
Tcl/Tk
That's a good choice. Another option is to use Racket: https://docs.racket-lang.org/gui/
>>2
The Racket option is heavyweight, and has far less community support than Tcl/Tk, which has been battle tested for decades in commercial and open source applications.
Does Guile have any libraries for GUIs? Their website has a link to GUI libraries but it does not actually lead to any GUI libraries: https://www.gnu.org/software/guile/libraries/#gui
>>4
Some options to investigate:
* guile-sdl https://www.gnu.org/software/guile-sdl/
* guile-opengl https://www.gnu.org/software/guile-opengl/
* guile-gnome https://www.gnu.org/software/guile-gnome/
Tcl/Tk
The most disgusting, bug-prone, alien looking shit I've ever seen. Tcl has taken the worst from Sh and Perl worlds and added its own uglinesses (such as encoding issues).
But it's available almost everywhere (I'm pretty sure you have 'wish' on your Linux) and helluva simple.
sdl
opengl
If you want a low-level GL instead of GUI toolkit.
I wish there was a sane HTML+CSS engine for building gui frontends with a real language, maybe something like https://github.com/tauri-apps/tauri
>>7
Start with Electron and write language bindings that can properly bind to Electron.
>>8
Every non-trivial Electron program that I've seen is fat and slow.
Why do people want to build GUI using HTML, it wasn't made for that.
it wasn't made for that
That was true for 1.0 spec. HTML5 has buttons and fields and canvas.
>>9
Those programmers don't understand the tools of performance profiling and parallel processing. It's perfectly feasible to write Electron software that feels responsive, those programmers don't understand how to do it.
>>12 If your framework requires parallel processing to feel responsive, it could have been done better.
>>13
Computer GUI responsiveness is a universal programming concern. From the Intel 386 computers with Windows 3.1, to the Nintendo Wii, all systems with graphical user interfaces need the programmers to do detailed analysis about the resource cost of drawing to the screen and responding to user inputs. Included in that analysis is detailed knowledge of which functionality that will "block" the computation. The way to mitigate such blockages in computing is with parallel processing that will segregate the concerns of taking user input and drawing a response, and segregate that from the other processes that we can expect to block.
>>1
Another option is to use Lazarus for creating cross-platform GUI.
https://en.wikipedia.org/wiki/Lazarus_(software)
I prefer haskell to laserous tbh desu
>>1
Why not use Qt? It is the industry standard for making cross-platform GUIs. It has relatively good tooling. It is open source and has a large open source community.
I use Rust and its GTK libs.
inb4 hipster tranny