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.
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.
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.
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.
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.
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…
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.
I think there are some native toolkits as well like McCLIM.
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)
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.
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.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.
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 (!!).
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.
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.
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…
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.
I think SBCL is the only Lisp that seems pay attention to trapping these kind of exceptions.