[fetter-devel] Qt bindings

[Ivan Shvedunov]

Hi.

On 11/2/05, C Y <smustudent1 at yahoo.com> wrote:
> --- Ivan Shvedunov <ivan4th at gmail.com> wrote:
>
> > > > That said, I think a good stable native open source
> > > > cross-platform Lisp GUI libary would be much better than Qt
> > > > bindings ;-)
> > >
> > > That would be McCLIM once it's done.  But to make it look and act
> > > "native" on various desktops, we want to interface with higher
> > > level graphics widgets rather than just taking low level
> > > primatives and doing everything ourselves. (which is what the clx
> > > backend currently does, as far as I can tell.)  If we then write a
> > > QT backend (which requires QT lisp bindings) we can write our
> > > interface in McCLIM (lisp) and then run it on all the platforms
> > > QT+Lisp runs on.  <evil grin>.
> >
> > Well, I think this would be really nice, but as far as I understand
> > only a little percentage of Qt functionality is necessary to write
> > the McCLIM backend.
>
> It might depend on how you wanted to implement the backend, but I
> suppose QT is so big that implementing all of the objects McCLIM would
> want to work with might still be a fairly small subset...
>
> I figured if Verrazano could be made to do a "two pass" scan or some
> such that could hook everything up with only a little extra work piping
> things through moc or using moc output to kind of "bind the bindings"
> it would be kind of neat to announce to the world that suddenly all of
> QT was available for any lisp implementation that supports Verrazano
> (THAT would interest some people.)  Maybe it's not as complicated as
> I'm thinking it would be...

No additional passes are necessary. GCCXML can process Qt header files
without any additional tools (as I've already said, all Qt directives
are converted
to valid C++ code by macros in Qt headers). Concerning MOC output ("metaobjects"
containing signals / slots / properties / etc.) - this info can be
easily sucked out
of compiled Qt code at runtime via QObject::metaObject()
(see also http://doc.trolltech.com/4.0/qmetaobject.html ). Of course some
additional macros may be introduced on Lisp side to process that info during
compile time.

So, there's nothing exceptionally special about Qt library. It can be interfaced
just like any other C++ library, and all special stuff like signals/slots can be
processed on Lisp side afterwards without much hassle and additional FFI /
source code parsing tricks.

> Unfortunately I don't have either Verrazano or QT4 on my home machine
> at the moment (and should probably wait for the rewrite in any case, if
> it's going to show up soon).  I guess I could burn a CD and get them
> on...
>
> > Such functionality can probably be wrapped with some simple C API
> > that can be easily accessible from Lisp, without any need to work
> > with Qt "metaobjects" (quotes are necessary to avoid blasphemy
> > against MOP :), signals, slots and so on.
>
> I think KDE defines something of the sort called Smoke (not sure if
> it's a C API) but I have no idea if it's cross platform.

Yes, also there's something called Kalyptus, this stuff was used to generate
QtC bindings (I didn't study that stuff much as I mostly used Qt from C++).

> If QT looks to take an unreasonably large amount of effort to get it
> working, the other option is to pour effort into Beagle and make
> backends for Win32/gdi, GTK, FLTK and maybe Smoke.  That would be a
> fair bit of effort but would achieve the same end - McCLIM on both Mac
> and Windows and on Gnome, KDE, and more minimalist Linux.

I think Qt backend can be viewed as a temporary solution, so that
McCLIM can be made more crossplatform "right now". More "direct" direct backends
would be better anyway (as there would be no Qt dependence).