1. 23
  1.  

  2. 6

    I think there are some native toolkits as well like McCLIM.

    1. 2

      There are, such as McCLIM and Garnet. McCLIM got an experiment working in the browser with Gtk’s Broadway protocol, and Garnet has an ongoing interface on Gtk.

      And there’s a new one in the works, Alloy, which can already be used in a game engine.

      (this is present in the introduction)

    2. 2

      The Common Lisp Qt4 bindings (along with QTools) was my favorite GUI toolkit for any language, and I miss it. Once Qt was installed, it “just worked” on both Linux and OSX, and it made GUI apps very easy to write.

      Unfortunately, Qt4 is a hassle to work with nowadays, and there’s no plans (that I know of) to support Qt5 any time soon. I’ve looked into porting the libraries over myself a couple of times, but it’s pretty complicated and there were some changes on the Qt side that made it even more so.

      1. 1

        Thanks for the feedback. A difficulty I have with Qtools is that it seems to not be very well discoverable: when I try to code-complete widget names, like (q+:label<TAB>), I get weird results. Maybe I missed something here.

        1. 1

          I don’t remember that, but it’s been a while since I’ve used it.

          Unfortunately, trying to load the package just now on FreeBSD is giving “Error opening shared object “…qtlibs!smokebase.so: program header too large.”

          I’ll boot up my Linux system this evening and see if I get the same problem.

        2. 1

          This probably isn’t the best time to get invested in Qt4, since KDE is doing a bunch of work on getting ready for a Qt6 migration (!!).

          1. 1

            Yes, I know. That’s why it was my favorite. LIke I said, Qt4 is difficult to use now so it’s not an option until the wrappers support a newer version of Qt.

            I’m not using KDE, though, so I don’t care which one they move to.

        3. 1

          Is Qt4 still viable for new development? Qt 5 shipped 2012-ish, if memory serves, and last time I tried to build a Qt 4 app (not for CL… for C++) on a relatively modern system (2018-ish) it was terribly painful. Maybe CL hides the pain but that doesn’t feel like something I’d like to rely on.

          1. 1

            Indeed CL hides the pain (it’s straightforward to install, develop and build the app), but I see what you mean… there’s some work ongoing for CL and Qt5 with CFFI and gobject-introspection, we’ll see if the attempts succeed…

          2. 1

            It’s a little shocking that gtk+ & IUP rely on silently dividing by zero. That seems like something one should guard against even if using a language like C.

            1. 1

              I think SBCL is the only Lisp that seems pay attention to trapping these kind of exceptions.