[fetter-devel] Qt bindings

[Ivan Shvedunov]

On 11/2/05, C Y <smustudent1 at yahoo.com> wrote:
>
>
> --- Ivan Shvedunov <ivan4th at gmail.com> wrote:
>
> > Well, as a former big Qt fan I just couldn't help myself...
> >
> > Concerning Qt bindings:
> > Qt headers aren't really using any non-standard C++. MOC directives
> > disappear if
> > you pass the file in question via preprocessor (they are #defined as
> > blank or something
> > like "signals" -> "protected"), so no special handling is required.
> > What MOC really does
> > is scanning header files for such directives and then generating
> > additional C++ source
> > containing "metaobjects", which contain slot descriptions etc. The
> > data from metaobjects
> > can be accessed and used by Lisp binding to connect signals to slots
> > and other related
> > tasks.
>
> Hmm :-).
>
> > Some additional ideas I had concerning Qt <-> Lisp interaction:
> >
> > 1. It's possible to generate XML-based .ui files easily from Lisp by
> > means of any
> > XML generator and then make Qt load them or convert them into C++
> > sources via
> > uic. This can be used to build GUI declaratively in Lisp.
>
> Could lisp then interface with the GUI though?  (send it data,
> commands, etc?)
>
> > 2. It's relatively easy to build a library which can interact with Qt
> > code by means of
> > calling members declared as slots, and probably do so via some simple
> > RPC protocol -
> > this can be useful for (somewhat strange) cases where GUI code is
> > written in C++
> > and application core is written in Lisp.
>
> Eeek.
>
> > 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.
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.