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

        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.

        2. 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.

        3. 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.

          2. 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…