[fetter-devel] Qt bindings

[C Y]

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

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.

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.  

Cheers,
CY


	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com