[fetter-devel] Qt bindings

[C Y]

--- Ivan Shvedunov <ivan4th at gmail.com> wrote:

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

OK.

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

Let me see if I'm following - so the idea would be to generate bindings
to the QT headers via gccxml, make an FFI on the compiled QT libraries
(which are post MOC conversion) and have the lisp interface use
QObject::metaObject() to handle the MOC induced differences?

> Of course some additional macros may be introduced on Lisp side to
> process that info during compile time.

But if we're using QObject::metaObject at runtime, what extra info do
we need from compile time?  (Sorry, I'm not very good at this FFI stuff
yet.)

Remember, QT library calls from lisp might never be compiled - they
might be input from the REPL.  

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

OK, that sounds encouraging.  Is that what QObject::metaObject allows? 
Information that would normally be irrelevant since C++ user code has
also gone through the MOC is available to be handled by the user
program if it so desires?

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

Hmm.  Well, since in the long run QT will likely be needed as an McCLIM
backend only for KDE on Linux, maybe the best course when the time
comes would be to look at the KDE provied mechanisms...

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

Agreed, except maybe the KDE desktop which is of course a special case.
 It might still be worth it though, since an McCLIM which is cross
platform "right now" with native look and feel on all platforms would
probably the best imaginable way to get some massive effort put into
it.  (Which it does need.)  And the Beagle backend is giving some
indiciations that writing the other backends could be a time consuming
process, and QT could buy the time needed.

Cheers,
CY
 



		
__________________________________ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs