Qt and Lisp...a great opportunity?

For folks that don't know, Nokia has decided to change to an LGPL license starting with Qt 4.5 in order to broaden usage of the toolkit. It's great news for those of us writing, or wanting to write, commercial applications using it. My company is currently using Qt and and we like it a lot...and we certainly won't miss paying for the commercial version

I am currently learning Lisp and am very hopeful that its combination of features and performance will let us move away from C++ for at least some of our future projects (we write graphics tools). Having a complete Lisp binding to Qt would be awesome as well as comforting in the sense that the toolkit would not be tied to a specific Lisp vendor. Qt really is very good and I am wondering if a high quality Lisp binding would be a big help in getting more people on board with the language. I know that it would be a significant factor for us.

As soon as I collect enough Lisp skills, I would certainly be willing to help in the effort.

There have been various stabs in the past to make a Qt binding for CL.

Writing a Qt binding is likely going to be more difficult than writing a GTK binding; Qt is C++, so that can add some complications. There is also the MOC you may want to deal with. Having the wrapper be lispy would be nice too...

There were several efforts to produce Qt binding (e.g., http://uint32t.blogspot.com/2008/07/qtl ... dback.html). But binding to Qt is hard, because it uses C++ (not evene plain C++, but modified C++). There seems to be some introspection mechanism in Qt (QMetaObject), it might be possible to use it to create bindings.
Producing a Gtk+ binding is easier. It uses plain C and has its own metaobject system (GObject). Actually, there are several project to create bindings to Gtk+ (gtk-cffi, clg, and I have an unpublished good but not yet complete binding).

There's no doubt that it would be a significant project for a number of reasons (C++, the Qt meta object compiler, etc.) I have seen the guy doing some work on a Qt binding already and he looks a bit lonely. From the perspective of a company creating commercial software, the look of Gtk is a bit of a turn-off as it doesn't seem to match the native look well. That judgment is mostly from working with GIMP and a few other Gtk based applications, and not working with the toolkit itself so it may not be a valid one.

Anyway, I do know that Qt is an excellent toolkit across platforms and a Lisp binding would grant one of my lispy wishes

August wrote:There's no doubt that it would be a significant project for a number of reasons (C++, the Qt meta object compiler, etc.) I have seen the guy doing some work on a Qt binding already and he looks a bit lonely. From the perspective of a company creating commercial software, the look of Gtk is a bit of a turn-off as it doesn't seem to match the native look well. That judgment is mostly from working with GIMP and a few other Gtk based applications, and not working with the toolkit itself so it may not be a valid one.

Anyway, I do know that Qt is an excellent toolkit across platforms and a Lisp binding would grant one of my lispy wishes

Qt moc seems to actually be a great help in the task of writing the binding. Because it allows to automatically gather information about classes and it provides general method of invoking methods and properties of objects.

I guess the main reason for absence of a complete Qt binding (and many other large libraries) is the lack of requrement for it. E.g., a single hacker starts the project for its fun, it gets semi-complete and then abandoned because at the time, noone needed it and the hacker's motivation is depleted. On the other, I think that it is possible for one man to create a complete Qt binding in the time of month or two.

For me, Gtk+ looks good, both on windows and linux.But that's just my opinion.

Clojure has full Qt/KDE bindings via Java, so that might be... something... ummm...

TheGZeus wrote:Clojure has full Qt/KDE bindings via Java, so that might be... something... ummm...

Not for long.?. QtJambi is now "community supported" -- Trolltech/Nokia are dropping official development.

On the plus side, this should mean they are opening the sources for the QtJambi toolset; these could be leveraged to generate a proper Lisp binding.

- Daniel

dmitry_vk wrote:Qt moc seems to actually be a great help in the task of writing the binding. Because it allows to automatically gather information about classes and it provides general method of invoking methods and properties of objects.

I guess the main reason for absence of a complete Qt binding (and many other large libraries) is the lack of requrement for it. E.g., a single hacker starts the project for its fun, it gets semi-complete and then abandoned because at the time, noone needed it and the hacker's motivation is depleted. On the other, I think that it is possible for one man to create a complete Qt binding in the time of month or two.

For me, Gtk+ looks good, both on windows and linux.But that's just my opinion.

Interesting, I hadn't considered that the Qt MOC would be a help in creating a Lisp binding. With Qt's change in licensing, I imagine that use of the toolkit will increase fairly dramatically so maybe there will be more interest in a complete and supported binding. I'm curious, do you folks know of many Lisp applications with a high quality GUI out there. There's InspireData which uses the Lispworks GUI, but I haven't run across much else.

Gtk+ does look good, it just misses on a few consistency points. The most glaring ones are the standard load/save dialogs. Is it easy to embed an OpenGL viewport in Gtk+? I will go have a closer look at the API.

As for Clojure, it looks good but is probably a no-go in my specific case for performance reasons. Yeah, I know about premature optimization, but there are some things in 3D graphics that just -have- to be fast (vector and matrix math, iterating over image data, etc). My understanding is that Common Lisp will let me put in type declarations, turn off safety, and so on in order to optimize specific sections of code. Being able program at a high level in general but retain the ability to really tune specific code paths would be a huge benefit to us.

Now that is something I would like - to be able to use Qt with CL. It looks really great - it has nice visual effects even for Windows 98 - and it must be very flexible - not that I ever really used it, though.

It is hard to see some CL aplication look good. There are a few programs that use McCLIM, but my experience with McCLIM was frustrating - don't know if I did something wrong or if McCLIM just didn't like me. It takes too long to load (I wouldn't like to have to wait that long to open firefox), and, specially the GTK interface, has bugs. The examples also where slow on my machine (and my machine is a dual-core, which should be enough).

What I really would like to see is an usefull and nice looking application written using Common Lisp - not entirely, it can use foreign libraries, but at least the main part. And, please, not an application known only among CL developers. Up to now, as far as I am concerned, only maxima is a well-known open-source application written using common-lisp. The only one I know at least, I can be wrong.

I can help, I have some experience with C and CFFI, but not C++. Unfortunatelly I don't think I have enough experience or patience to do such a complex wrapper like this one by myself, and I still don't know someone else who can help. I wouldn't mind about the opengl, dbus and other stuff that Qt supports, these will be much better as separated libraries (e.g. cl-opengl and cl-dbus), but I definitely would be happy to see bindings for the graphical toolkit. Perhaps even a parser for the XML file that the Qt Designer produces - I guess this way it would be possible to use Qt Designer to create interface for Lisp programs (How cool is that?).

I have thought about markup like html, latex, and i have thought about gui's then i tend to think more generally and more generally. I think the best gui that can in principle exist can also do markup and vice-versa. If the code is restricted so some behaviors it should be able to convert to html-like stuff, javascript/other if not restricted, on the other hand, it should also be able to convert to gui systems like gtk, qt etc. If lisp could do that, it might be a 'killer app'.
Haven't figured out how to do it exactly; is it better to have a markup side and let code interact with that, or to have the markup side be just code, that can be analyzed to produce html/documents and such. Due to what i learned making a loop-like macro(i'll probably start thread about that later), i suspect it is the latter. Edit: of course, 'the best markup in principle' is maybe a little bit of a too lofty goal.

As for qt itself, i don't really know much about it..

I've used QtJambi in Clojure to good effect. Very easy to get up and running quickly. Worked cross-platform with no problems. Very well-documented. It's sad to hear QtJambi is losing official support and going "community", but at least version 4.5 is there to use.

August wrote:As for Clojure, it looks good but is probably a no-go in my specific case for performance reasons. Yeah, I know about premature optimization, but there are some things in 3D graphics that just -have- to be fast (vector and matrix math, iterating over image data, etc). My understanding is that Common Lisp will let me put in type declarations, turn off safety, and so on in order to optimize specific sections of code. Being able program at a high level in general but retain the ability to really tune specific code paths would be a huge benefit to us.

You can have type declarations and primitive unchecked integer/floating point arithmetic in Clojure if you want it. http://clojure.org/java_interop#toc36 Clojure can be just about as fast as Java. Not sure if that's fast enough but it might be worth a try.

Unne wrote:You can have type declarations and primitive unchecked integer/floating point arithmetic in Clojure if you want it. http://clojure.org/java_interop#toc36 Clojure can be just about as fast as Java. Not sure if that's fast enough but it might be worth a try.

Thanks much for the info! I will definitely do some performance testing with Clojure as part of my Lisp research. The thing I like about Common Lisp is that you can easily get a look at the disassembly. In my particular case, we would likely have a couple of code paths where we would want to get the "as fast as C/C++" claims working

Unne wrote:I've used QtJambi in Clojure to good effect. Very easy to get up and running quickly. Worked cross-platform with no problems. Very well-documented. It's sad to hear QtJambi is losing official support and going "community", but at least version 4.5 is there to use.

Well, it is more or less ok, I heard Nokia will support it for one year. On the other hand, about the community keeping Qt Jambi up to date, well...

Unne wrote:You can have type declarations and primitive unchecked integer/floating point arithmetic in Clojure if you want it. http://clojure.org/java_interop#toc36 Clojure can be just about as fast as Java. Not sure if that's fast enough but it might be worth a try.

Well, I didn't know that, this seems good news. I have a bad feeling about java, though - it looks like that it's too heavy, you can't write small and reasonably fast applications. I can be wrong right know, I'm saying that because I already have used Eclipse (with cusp, it is a good option for beginners like I was back then - but you have to open it once and keep it open, because opening it frequently is frustrating) and I also downloaded Jubbler once (a VERY SLOW program to edit subtitles).

Anyway, not saying anything against Clojure itself, it looks to have nice features (which I envy - although I didn't try it).

The JVM is heavy and it takes a while to start, and it's an enormous memory hog, but once it's running it goes fast. In my (limited) experience QtJambi apps run about as fast as native Qt apps once they're up and running. In practice this isn't that much of an issue, because Clojure like any other Lisp is meant to be started once in a blue moon, and then you play at the REPL.

The other bad thing about QtJambi is that there are issues with memory leaks due to the way Qt disposes of objects, and the separate garbage collector in the JVM not playing nicely together. (See e.g. here.) I imagine that would be a problem for any other garbage-collected language too though. You can easily work around this but it's a pain.

On the other hand QtJambi works pretty well from the Clojure REPL, you can fiddle with Qt objects and re-compile event handlers while your app is running and other such fun. It integrates well with native Java threads too, which Clojure can put to good use.

It'd be cool to have Qt4 bindings for Common Lisp, that's something I've wanted for a while before I jumped ship for Clojure. Supposedly it's not too hard to do nowadays if you use Smoke. There are even PHP bindings for Qt4. Surely Common Lisp can beat PHP.

Unne wrote:The JVM is heavy and it takes a while to start, and it's an enormous memory hog, but once it's running it goes fast. In my (limited) experience QtJambi apps run about as fast as native Qt apps once they're up and running. In practice this isn't that much of an issue, because Clojure like any other Lisp is meant to be started once in a blue moon, and then you play at the REPL.

Yes, it takes a while to start, which means you can't create desktop programs with it, for instance. Maybe an Internet Browser, but it can't do too much initialization. A solution is to create a server and let it keep running (waiting) in the background, but it would be difficult to do such a thing if the user don't like the idea of having one hundred megabytes of RAM gone forever.

I guess the same idea can be done with SBCL, or Common Lisp in general - let a small C program try to communicate with CL through a socket (or DBUS), and make the implementation run some code or load some file in a separated thread. I'll try to do this on my machine in a near future.

Unne wrote:It'd be cool to have Qt4 bindings for Common Lisp, that's something I've wanted for a while before I jumped ship for Clojure. Supposedly it's not too hard to do nowadays if you use Smoke. There are even PHP bindings for Qt4. Surely Common Lisp can beat PHP.

Nice! Understanding Smoke and maybe use it to create an interface is added to my WISH-TO-DO list (now that's a big list... ). I wonder if MOP can help doing such a binding. Specializing the function slot-value-using-class to access the foreign code as if it where a slot in a CL class, specialize compute-class-precedence-list, creating subclasses of Qt classes as if they where CLOS classes...

Unne wrote:The other bad thing about QtJambi is that there are issues with memory leaks due to the way Qt disposes of objects, and the separate garbage collector in the JVM not playing nicely together.

That's bad. For Gtk, memory management is better — it is easy to use it in garbage-collected language and not have memory leaks or prematurely destroyed objects.

dmitry_vk wrote:

Unne wrote:The other bad thing about QtJambi is that there are issues with memory leaks due to the way Qt disposes of objects, and the separate garbage collector in the JVM not playing nicely together.

That's bad. For Gtk, memory management is better — it is easy to use it in garbage-collected language and not have memory leaks or prematurely destroyed objects.

Qt's memory management is quite good. I suspect the problems relate to the binding, not the library. The only difficulty I've had with Qt is the need to sometimes call deleteLater() rather than delete().

Just today as i browsed through Hacker News i found this link, a Common Lisp binding to the smoke interface to QT. I thought this should interest some of the people following this thread.

CommonQT

Wow, nice! This is a great new.