From rayiner at gmail.com  Tue Nov  1 20:31:03 2005
From: rayiner at gmail.com (Rayiner Hashem)
Date: Tue, 1 Nov 2005 15:31:03 -0500
Subject: [fetter-devel] Couple of probably silly questions
In-Reply-To: <20051030172522.90636.qmail@web31713.mail.mud.yahoo.com>
References: <20051030172522.90636.qmail@web31713.mail.mud.yahoo.com>
Message-ID: <d082aad0511011231x3af2c424r1d568efbebe58480@mail.gmail.com>

> a)  If a library on (say) Windows has been compiled with Visual C++,
> and another with gcc in mingw, will I be able to access the
> functionality of both binary C++ libraries from Lisp and use both in
> the same application?

Yes. Since the ABI details are embedded into the bindings, the ABI is
per-binding, not per-application.

> b)  Has anyone yet taken a crack at QT, or will that need the retooled
> C++ support?

QT isn't regular C++ code. Its header files, as well as any programs
that use it, are not regular C++. VZN could bind to the MOC-processed
headers, but since there is no "MOC for Lisp", Lisp programs couldn't
use the resulting library comfortably. This problem is solvable, as
Python has rather good Qt bindings, and Vzn would likely make the task
easier, but significant extra work will be required.

> c)  Does anybody know what the current status of GCL support?  Is
> anybody still working on it or is GCL too far out of spec right now to
> be able to have any chance of handling it?

GCL could likely run Verrazano, but I think the problem is that it
can't run C-FFI.

>
> Cheers,
> CY
>
>
>
> __________________________________
> Yahoo! FareChase: Search multiple travel sites in one click.
> http://farechase.yahoo.com
> _______________________________________________
> fetter-devel mailing list
> fetter-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel
>


From smustudent1 at yahoo.com  Tue Nov  1 21:18:25 2005
From: smustudent1 at yahoo.com (C Y)
Date: Tue, 1 Nov 2005 13:18:25 -0800 (PST)
Subject: [fetter-devel] Couple of probably silly questions
In-Reply-To: <d082aad0511011231x3af2c424r1d568efbebe58480@mail.gmail.com>
Message-ID: <20051101211826.56155.qmail@web31714.mail.mud.yahoo.com>

--- Rayiner Hashem <rayiner at gmail.com> wrote:

> > a)  If a library on (say) Windows has been compiled with Visual
> > C++, and another with gcc in mingw, will I be able to access the
> > functionality of both binary C++ libraries from Lisp and use both
> > in the same application?
> 
> Yes. Since the ABI details are embedded into the bindings, the ABI is
> per-binding, not per-application.
> 
> > b)  Has anyone yet taken a crack at QT, or will that need the
> > retooled C++ support?
> 
> QT isn't regular C++ code. Its header files, as well as any programs
> that use it, are not regular C++. VZN could bind to the MOC-processed
> headers, but since there is no "MOC for Lisp", Lisp programs couldn't
> use the resulting library comfortably. 

Crud.  I'm a bit confused - MOC is a pre-processor which generates
valid C++ code to compile from QT libraries.  We could presumably
generate bindings based on the QT source code using gcc-xml, but I
gather they would not represent an interface to the level of object the
user would want to use but an interface to the legal C++ interfaces
generated by the MOC pre-processor?  I take it MOC must be used on any
user code written using QT bindings as well?  So we would need a QT
Lisp bindings -> Vzn generated post MOC QT bindings translator, which
means duplicating the MOC logic in Lisp?

> This problem is solvable, as Python has rather good Qt bindings, and
> Vzn would likely make the task easier, but significant extra work 
> will be required.

It looks like this might be a useful discussion, once I figure out what
on earth they're talking about:
http://mail.kde.org/pipermail/kde-bindings/2005-August/001289.html

Python has QT3 bindings, but for QT4 it looks like they are still in
early development stage

Blast. QT4 has been released as GPL for Windows, Mac and Linux with an
apparently native look on all three - why oh why does it have to be the
tough target?  Auugh.

I wonder if Trolltech would be interested in this at all?  CFFI's
license is no problem for commercial use, and I'm assuming Verrazano's
isn't either (I can't find it offhand, but it wouldn't make sense to
exclude commercial use when universality is the goal...) but to deploy
any commerical Lisp app using QT bindings a commercial QT license would
be needed.  Dunno how much potential market there is, but surely QT
lisp bindings wouldn't hurt Trolltech.  In one sense, given robust
bindings QT+Lisp might even present a viable alternative to Java for
cross platform graphical application development.
 
> > c)  Does anybody know what the current status of GCL support?  Is
> > anybody still working on it or is GCL too far out of spec right now
> > to be able to have any chance of handling it?
> 
> GCL could likely run Verrazano, but I think the problem is that it
> can't run C-FFI.

OK.  Hopefully matters will improve with 2.7.0  Thanks!

CY

*Irrelevant note to self - try C-FFI with the zic graphics libraries.


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


From luismbo at gmail.com  Tue Nov  1 22:08:41 2005
From: luismbo at gmail.com (Luis Oliveira)
Date: Tue, 1 Nov 2005 22:08:41 +0000
Subject: [fetter-devel] Couple of probably silly questions
In-Reply-To: <20051030172522.90636.qmail@web31713.mail.mud.yahoo.com>
References: <20051030172522.90636.qmail@web31713.mail.mud.yahoo.com>
Message-ID: <2cf4d334b5341f304cf669b7dc6fce56@gmail.com>

On 30/out/2005, at 17:25, C Y wrote:
> b)  Has anyone yet taken a crack at QT, or will that need the retooled
> C++ support?

It seems Wilco Greven was working on this:
http://common-lisp.net/pipermail/cffi-devel/2005-August/000007.html

-- 
Lu?s Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt



From smustudent1 at yahoo.com  Wed Nov  2 01:36:05 2005
From: smustudent1 at yahoo.com (C Y)
Date: Tue, 1 Nov 2005 17:36:05 -0800 (PST)
Subject: [fetter-devel] QT, MOC, and Verrazano
In-Reply-To: <20051101211826.56155.qmail@web31714.mail.mud.yahoo.com>
Message-ID: <20051102013606.90621.qmail@web31702.mail.mud.yahoo.com>

Sorry to reply to my own post, but I have a question/half baked idea
about MOC and QT I want to get down before I lose it.

QT is intended as a C++ toolkit, but apparently uses structures above
and beyond those of C++.  This requires both user applications and the
libraries themselves? to utilize a pre-processor tool which translates
QT code into valid C++ code.  

When Verrazano generates bindings, does it work solely from the xml
output of the gcc-xml compile?  E.g., does it look at the original
files in question or just the gcc-xml data?  (Sorry, I should know
this...)

If it DOES look at the actual source code or header files to generate
the actual bindings, is there any way a second layer could be inserted?
 I'm thinking something like this:

a)  Verrazano scans the QT files in question, generating bindings for
the toplevel QT calls.  These do not correspond to the actual C++
compiled output of course, any more than any user level code does
before being translated by MOC.

b)  On a per-binding basic, call moc on the C++ associated with the
binding to generate a post-MOC set of bindings.  Run Verrazano in a
second pass to generate bindings for the results.  Automatically link
up the top level QT FFI to the post-MOC FFI bindings generated
(hopefully this will be possible.)

c)  use the post-MOC generated FFI to link up with the results of the
normal gcc-xml build information.

In effect, rather than implement the entire MOC in Lisp, the idea would
be to use it as a converter on a per-entry basis and work with the
results.  This has an advantage in that a Lisp verson of the MOC won't
have to be written, maintained and updated.  Of course the
disadvantages are:  a) Verrazano may not work in a way that makes this
even remotely feasible b) the MOC output may not have inputs that are
easily relatible to the inputs given to the QT level FFI (although
hopefully this will either be apparent or easily deduced) c) the MOC
may not care to be run on such small parts of a file d) it might be a
very slow way to generate bindings and e) the QT files themselves may
not be readable from Verrazano's perspective, depending on how
different they actually are compared to regular C++ syntax.  Maybe
gcc-xml could be tweaked to output xml for them without trying to
compile them (which obviously wouldn't work?)  It would be a shame to
have to write a special generator just for QT files.

Anyway, probably total nonsense but I thought it was an idea worth
mentioning in case someone knowing more about QT could judge how bad of
an idea it really is.  Maybe if it's a workable idea it would even be a
useful mechanism to have in place, in case of other pre-processed C++
libraries?  (just replace moc with the name of the preprocessor for the
particular library in question?)

Cheers,
CY


		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com


From rayiner at gmail.com  Wed Nov  2 05:17:33 2005
From: rayiner at gmail.com (Rayiner Hashem)
Date: Wed, 2 Nov 2005 00:17:33 -0500
Subject: [fetter-devel] Couple of probably silly questions
In-Reply-To: <20051101211826.56155.qmail@web31714.mail.mud.yahoo.com>
References: <d082aad0511011231x3af2c424r1d568efbebe58480@mail.gmail.com>
	<20051101211826.56155.qmail@web31714.mail.mud.yahoo.com>
Message-ID: <d082aad0511012117v19a7437bj852a630d29a3f8bb@mail.gmail.com>

> Crud.  I'm a bit confused - MOC is a pre-processor which generates
> valid C++ code to compile from QT libraries.

Yes.

>  We could presumably
> generate bindings based on the QT source code using gcc-xml, but I
> gather they would not represent an interface to the level of object the
> user would want to use but an interface to the legal C++ interfaces
> generated by the MOC pre-processor?

Yep.

>  I take it MOC must be used on any
> user code written using QT bindings as well?

Yes, I presume it translates Qt-specific constructs into the low-level
form expected at the library level.

>  So we would need a QT
> Lisp bindings -> Vzn generated post MOC QT bindings translator, which
> means duplicating the MOC logic in Lisp?

Kinda. What libraries like PyQt do is present a native-language
version of the low-level interface that results when MOC is run on the
Qt header files. The trick would be to write something similar for
Lisp.

> Blast. QT4 has been released as GPL for Windows, Mac and Linux with an
> apparently native look on all three - why oh why does it have to be the
> tough target?  Auugh.

QT4 is supposedly easier to target than QT3, because it has some
specific metacall facillities. However, its mainly intended for
dynamic languages that can introspect the library at runtime. It seems
like of a waste on Lisp, which is compiled and could bind statically
to the library just like C++.

>
> I wonder if Trolltech would be interested in this at all?  CFFI's
> license is no problem for commercial use, and I'm assuming Verrazano's
> isn't either (I can't find it offhand, but it wouldn't make sense to
> exclude commercial use when universality is the goal...)

Vzn is BSD licensed.

> but to deploy
> any commerical Lisp app using QT bindings a commercial QT license would
> be needed.  Dunno how much potential market there is, but surely QT
> lisp bindings wouldn't hurt Trolltech.  In one sense, given robust
> bindings QT+Lisp might even present a viable alternative to Java for
> cross platform graphical application development.
>
> > > c)  Does anybody know what the current status of GCL support?  Is
> > > anybody still working on it or is GCL too far out of spec right now
> > > to be able to have any chance of handling it?
> >
> > GCL could likely run Verrazano, but I think the problem is that it
> > can't run C-FFI.
>
> OK.  Hopefully matters will improve with 2.7.0  Thanks!
>
> CY
>
> *Irrelevant note to self - try C-FFI with the zic graphics libraries.
>
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors' Choice 2005
> http://mail.yahoo.com
>


From ivan4th at gmail.com  Wed Nov  2 09:05:33 2005
From: ivan4th at gmail.com (Ivan Shvedunov)
Date: Wed, 2 Nov 2005 12:05:33 +0300
Subject: [fetter-devel] Qt bindings
Message-ID: <4d93c5bf0511020105m6b03f012n4a8ed020a197704e@mail.gmail.com>

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.

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.

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.

That said, I think a good stable native open source cross-platform
Lisp GUI libary would
be much better than Qt bindings ;-)


From smustudent1 at yahoo.com  Wed Nov  2 13:32:24 2005
From: smustudent1 at yahoo.com (C Y)
Date: Wed, 2 Nov 2005 05:32:24 -0800 (PST)
Subject: [fetter-devel] Qt bindings
In-Reply-To: <4d93c5bf0511020105m6b03f012n4a8ed020a197704e@mail.gmail.com>
Message-ID: <20051102133224.66318.qmail@web31711.mail.mud.yahoo.com>



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

Cheers,
CY


		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com


From ivan4th at gmail.com  Wed Nov  2 13:55:12 2005
From: ivan4th at gmail.com (Ivan Shvedunov)
Date: Wed, 2 Nov 2005 16:55:12 +0300
Subject: [fetter-devel] Qt bindings
In-Reply-To: <20051102133224.66318.qmail@web31711.mail.mud.yahoo.com>
References: <4d93c5bf0511020105m6b03f012n4a8ed020a197704e@mail.gmail.com>
	<20051102133224.66318.qmail@web31711.mail.mud.yahoo.com>
Message-ID: <4d93c5bf0511020555k20ea958dq33cbaf12211f1227@mail.gmail.com>

On 11/2/05, C Y <smustudent1 at yahoo.com> wrote:
>
>
> --- Ivan Shvedunov <ivan4th at gmail.com> wrote:
> > 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?)

This problem needs to be dealt with separately. But once GUI is constructed,
many tasks can be accomplished by means of working with exposed signals/slots
and properties only, which can be done with minimal FFI usage (this is related
to the case when Qt is used as primary GUI library, not just for
McCLIM backend).


From ivan4th at gmail.com  Wed Nov  2 13:43:32 2005
From: ivan4th at gmail.com (Ivan Shvedunov)
Date: Wed, 2 Nov 2005 16:43:32 +0300
Subject: [fetter-devel] Qt bindings
In-Reply-To: <20051102133224.66318.qmail@web31711.mail.mud.yahoo.com>
References: <4d93c5bf0511020105m6b03f012n4a8ed020a197704e@mail.gmail.com>
	<20051102133224.66318.qmail@web31711.mail.mud.yahoo.com>
Message-ID: <4d93c5bf0511020543y5ca0d3edv74fddf4c6bcf3ae3@mail.gmail.com>

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.


From smustudent1 at yahoo.com  Wed Nov  2 14:28:42 2005
From: smustudent1 at yahoo.com (C Y)
Date: Wed, 2 Nov 2005 06:28:42 -0800 (PST)
Subject: [fetter-devel] Qt bindings
In-Reply-To: <4d93c5bf0511020543y5ca0d3edv74fddf4c6bcf3ae3@mail.gmail.com>
Message-ID: <20051102142842.52193.qmail@web31715.mail.mud.yahoo.com>

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


From ivan4th at gmail.com  Wed Nov  2 14:54:40 2005
From: ivan4th at gmail.com (Ivan Shvedunov)
Date: Wed, 2 Nov 2005 17:54:40 +0300
Subject: [fetter-devel] Qt bindings
In-Reply-To: <20051102142842.52193.qmail@web31715.mail.mud.yahoo.com>
References: <4d93c5bf0511020543y5ca0d3edv74fddf4c6bcf3ae3@mail.gmail.com>
	<20051102142842.52193.qmail@web31715.mail.mud.yahoo.com>
Message-ID: <4d93c5bf0511020654r7e493162rd345695b4310028e@mail.gmail.com>

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


From smustudent1 at yahoo.com  Wed Nov  2 15:23:54 2005
From: smustudent1 at yahoo.com (C Y)
Date: Wed, 2 Nov 2005 07:23:54 -0800 (PST)
Subject: [fetter-devel] Qt bindings
In-Reply-To: <4d93c5bf0511020654r7e493162rd345695b4310028e@mail.gmail.com>
Message-ID: <20051102152354.81121.qmail@web31707.mail.mud.yahoo.com>


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


From joesb.coe9 at gmail.com  Fri Nov  4 07:14:46 2005
From: joesb.coe9 at gmail.com (JoeSB COE9)
Date: Fri, 4 Nov 2005 14:14:46 +0700
Subject: [fetter-devel] Header with only #define not exported.
Message-ID: <bd1a1900511032314t4bad65e0t7af41ce3a1b04c32@mail.gmail.com>

I resent this as the last one sent two days agoes doesnot appear on the list.

On 10/23/05, Rayiner Hashem <rayiner at gmail.com> wrote:
> It was a silly bug in the macro parser. It's fixed in CVS. Thanks for
> the report.
>
> Sincerely,
>     Rayiner Hashem
>

Thanks, now that little toy include file passes but Opengl define
still does not get exported :(

I use VC++6, and its GL include file from Visual C++.

More over, I came up with a new test case. It might not the test case
for my Opengl binding problem, but it surely makes VZN more robust :)

If my include file only contains:

----------------------------
//includeme.h
#define AN_DEF1 1
#define AN_DEF2 1
#define AN_DEF3 1
----------------------------

The resulting lisp file will not have these three define exported.
However if I add a line to the include file above

----------------------------
//includeme.h
#define AN_DEF1 1
#define AN_DEF2 1
#define AN_DEF3 1

enum eee {a, b};
----------------------------

Now result lisp file contains both definition of eee enum and ANDEFX defines.

.mac files always contains those #defines.

Seems like VZN does not parsed correctly include file with only
#define's. Too lazily output, may be?

From rif at MIT.EDU  Fri Nov 11 21:08:06 2005
From: rif at MIT.EDU (rif)
Date: Fri, 11 Nov 2005 16:08:06 -0500
Subject: [fetter-devel] Trying to get started (problems with require)
Message-ID: <200511112108.jABL8610028824@five-percent-nation.mit.edu>


I'm trying to follow the instructions at
http://common-lisp.net/project/fetter/getting-started.html using CMUCL
19A.  I'm using the CVS versions of verrazano and CFFI (downloaded
today 11 Nov 2005, cffi-luis branch).

Eventually, I figured out I needed to asdf-install :parse-number and
:s-xml (this should probably be added to the getting started page).
At this point, I can run generate the demos with the appropriate
generate.lisp file, but when I try to actually run one, I get an
error.  In my .cmucl-init file, I am loading CFFI (by pushing the
directory onto my asdf:*central-registry* and then asdf:load-op'ing
it), but the command

(require 'cffi)

is failing with 

Error in function REQUIRE:  Don't know how to load CFFI.

What am I doing wrong?

Cheers,

rif


From asimon at math.bme.hu  Fri Nov 11 21:21:16 2005
From: asimon at math.bme.hu (Andras Simon)
Date: Fri, 11 Nov 2005 22:21:16 +0100 (CET)
Subject: [fetter-devel] Trying to get started (problems with require)
In-Reply-To: <200511112108.jABL8610028824@five-percent-nation.mit.edu>
References: <200511112108.jABL8610028824@five-percent-nation.mit.edu>
Message-ID: <Pine.LNX.4.60.0511112216590.16048@csusza.math.bme.hu>



On Fri, 11 Nov 2005, rif wrote:

>
> I'm trying to follow the instructions at
> http://common-lisp.net/project/fetter/getting-started.html using CMUCL
> 19A.  I'm using the CVS versions of verrazano and CFFI (downloaded
> today 11 Nov 2005, cffi-luis branch).
>
> Eventually, I figured out I needed to asdf-install :parse-number and
> :s-xml (this should probably be added to the getting started page).
> At this point, I can run generate the demos with the appropriate
> generate.lisp file, but when I try to actually run one, I get an
> error.  In my .cmucl-init file, I am loading CFFI (by pushing the
> directory onto my asdf:*central-registry* and then asdf:load-op'ing
> it), but the command
>
> (require 'cffi)
>
> is failing with
>
> Error in function REQUIRE:  Don't know how to load CFFI.
>
> What am I doing wrong?

REQUIRE doesn't know about asdf:*central-registry*, so this is to be
expected. But why are you REQUIREing cffi when it's loaded already by asdf?

Andras


From smustudent1 at yahoo.com  Fri Nov 11 21:27:28 2005
From: smustudent1 at yahoo.com (C Y)
Date: Fri, 11 Nov 2005 13:27:28 -0800 (PST)
Subject: [fetter-devel] Trying to get started (problems with require)
In-Reply-To: <200511112108.jABL8610028824@five-percent-nation.mit.edu>
Message-ID: <20051111212728.79147.qmail@web31709.mail.mud.yahoo.com>



--- rif <rif at MIT.EDU> wrote:

> Eventually, I figured out I needed to asdf-install :parse-number 

Is there a way to handle parse number other than asdf-install?  My
machine is off the net and what I finally wound up doing was
downloading and slightly tweaking parse-number and writing an asdf file
for it myself.  Was there some other version I could have downloaded
that had an asdf file already included?

I agree parse-number should be included in the requirements list -
downloaded everything but that my first go-around ;-)

Cheers,
CY


		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com


From asimon at math.bme.hu  Fri Nov 11 21:37:34 2005
From: asimon at math.bme.hu (Andras Simon)
Date: Fri, 11 Nov 2005 22:37:34 +0100 (CET)
Subject: [fetter-devel] Trying to get started (problems with require)
In-Reply-To: <20051111212728.79147.qmail@web31709.mail.mud.yahoo.com>
References: <20051111212728.79147.qmail@web31709.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.60.0511112234030.16048@csusza.math.bme.hu>



On Fri, 11 Nov 2005, C Y wrote:

>
>
> --- rif <rif at MIT.EDU> wrote:
>
>> Eventually, I figured out I needed to asdf-install :parse-number
>
> Is there a way to handle parse number other than asdf-install?  My
> machine is off the net and what I finally wound up doing was
> downloading and slightly tweaking parse-number and writing an asdf file
> for it myself.  Was there some other version I could have downloaded
> that had an asdf file already included?

parse-number.asd is in the huge tarball
http://common-lisp.net/project/asdf-packaging/parse-number-latest.tar.gz

Andras


From rif at MIT.EDU  Fri Nov 11 21:43:00 2005
From: rif at MIT.EDU (rif)
Date: Fri, 11 Nov 2005 16:43:00 -0500
Subject: [fetter-devel] Trying to get started (problems with require)
In-Reply-To: Your message of "Fri, 11 Nov 2005 22:21:16 +0100."
	<Pine.LNX.4.60.0511112216590.16048@csusza.math.bme.hu> 
Message-ID: <200511112143.jABLh1p1029104@five-percent-nation.mit.edu>


> 
> 
> On Fri, 11 Nov 2005, rif wrote:
> 
> >
> > I'm trying to follow the instructions at
> > http://common-lisp.net/project/fetter/getting-started.html using CMUCL
> > 19A.  I'm using the CVS versions of verrazano and CFFI (downloaded
> > today 11 Nov 2005, cffi-luis branch).
> >
> > Eventually, I figured out I needed to asdf-install :parse-number and
> > :s-xml (this should probably be added to the getting started page).
> > At this point, I can run generate the demos with the appropriate
> > generate.lisp file, but when I try to actually run one, I get an
> > error.  In my .cmucl-init file, I am loading CFFI (by pushing the
> > directory onto my asdf:*central-registry* and then asdf:load-op'ing
> > it), but the command
> >
> > (require 'cffi)
> >
> > is failing with
> >
> > Error in function REQUIRE:  Don't know how to load CFFI.
> >
> > What am I doing wrong?
> 
> REQUIRE doesn't know about asdf:*central-registry*, so this is to be
> expected. But why are you REQUIREing cffi when it's loaded already by asdf?

I am REQUIREing cffi because the test.lisp file that comes with verrazano includes the line

(require 'cffi)

Am I meant to have to modify this file myself and load cffi
separately?

rif


From asimon at math.bme.hu  Fri Nov 11 21:55:38 2005
From: asimon at math.bme.hu (Andras Simon)
Date: Fri, 11 Nov 2005 22:55:38 +0100 (CET)
Subject: [fetter-devel] Trying to get started (problems with require)
In-Reply-To: <200511112143.jABLh1p1029104@five-percent-nation.mit.edu>
References: <200511112143.jABLh1p1029104@five-percent-nation.mit.edu>
Message-ID: <Pine.LNX.4.60.0511112249510.16048@csusza.math.bme.hu>



On Fri, 11 Nov 2005, rif wrote:

>
> I am REQUIREing cffi because the test.lisp file that comes with verrazano includes the line
>
> (require 'cffi)
>
> Am I meant to have to modify this file myself and load cffi
> separately?

REQUIREing could be a way to check that cffi is loaded if cffi
PROVIDEd cffi. But it doesn't. So I think (require 'cffi) should go.

Someone will hopefully correct me if I'm missing something. 
Until then, just load cffi (with asdf).

Andras



From luismbo at gmail.com  Fri Nov 11 22:02:41 2005
From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=)
Date: Fri, 11 Nov 2005 22:02:41 +0000
Subject: [fetter-devel] Trying to get started (problems with require)
In-Reply-To: <200511112143.jABLh1p1029104@five-percent-nation.mit.edu>
References: <200511112143.jABLh1p1029104@five-percent-nation.mit.edu>
Message-ID: <7F75FA6B-2B7D-43EC-8273-37F51FAE5280@gmail.com>

On 2005-nov-11, at 21:43, rif wrote:
> I am REQUIREing cffi because the test.lisp file that comes with  
> verrazano includes the line
>
> (require 'cffi)
>
> Am I meant to have to modify this file myself and load cffi
> separately?

That's probably because Rayiner's main platform is SBCL (iirc) and  
SBCL's REQUIRE knows about ASDF. Just change that to:

   (asdf:operate 'asdf:load-op :cffi)

-- 
Lu?s Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt



From rif at MIT.EDU  Mon Nov 14 22:17:23 2005
From: rif at MIT.EDU (rif)
Date: Mon, 14 Nov 2005 17:17:23 -0500
Subject: [fetter-devel] Trying to get started (problems with require)
In-Reply-To: Your message of "Fri, 11 Nov 2005 22:02:41 GMT."
	<7F75FA6B-2B7D-43EC-8273-37F51FAE5280@gmail.com> 
Message-ID: <200511142217.jAEMHNQY019412@five-percent-nation.mit.edu>


OK, I'm still a bit confused and haven't succeeded in getting the
demos working.  I commented out the

(require 'cffi) line in (for instance) test.lisp.

But what is verrazano-support?  vfun/test.lisp "require"'s it, and
vfun-library.lisp wants to asdf:load-op it, but I cannot seem to find
a definition of it anywhere in the distribution.

Cheers,

rif


From asimon at math.bme.hu  Mon Nov 14 22:42:46 2005
From: asimon at math.bme.hu (Andras Simon)
Date: Mon, 14 Nov 2005 23:42:46 +0100 (CET)
Subject: [fetter-devel] Trying to get started (problems with require)
In-Reply-To: <200511142217.jAEMHNQY019412@five-percent-nation.mit.edu>
References: <200511142217.jAEMHNQY019412@five-percent-nation.mit.edu>
Message-ID: <Pine.LNX.4.60.0511142335180.16048@csusza.math.bme.hu>



On Mon, 14 Nov 2005, rif wrote:

>
> OK, I'm still a bit confused and haven't succeeded in getting the
> demos working.  I commented out the
>
> (require 'cffi) line in (for instance) test.lisp.
>
> But what is verrazano-support?  vfun/test.lisp "require"'s it, and
> vfun-library.lisp wants to asdf:load-op it, but I cannot seem to find
> a definition of it anywhere in the distribution.

verrazano-support is the runtime part of verrazano. From
http://common-lisp.net/project/fetter/getting-started.html:

| Verrazano itself is distributed in two parts, corresponding to two
| modules in the CVS repository. The main program is in the 'verrazano'
| module, while the support library is in the 'verrazano-support'
| module. Both programs can be acquired by using the "download tarball"
| feature from the viewcvs webpage.

Or check it out from cvs.

I hope this helps,

Andras


From ktilton at nyc.rr.com  Sat Nov 19 16:49:23 2005
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Sat, 19 Nov 2005 11:49:23 -0500
Subject: [fetter-devel] VC++ Support?
Message-ID: <437F5793.7010101@nyc.rr.com>

Is there a new release of Verrazano on the way? I am especially anxious 
to get that VC++ support, as well as that more detailed control of which 
symbols get exported based on where they are found in the source tree.

Someone asked about my cl-ftgl library and I realized it was in limbo 
waiting for both enhancements. I could always roll back to using C glue, 
but if a new Vzn is on the way I would prefer using that.

-- 
Kenny

Why Lisp? http://wiki.alu.org/RtL_Highlight_Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it."
    Elwood P. Dowd, "Harvey", 1950





From rayiner at gmail.com  Sat Nov 19 21:37:04 2005
From: rayiner at gmail.com (Rayiner Hashem)
Date: Sat, 19 Nov 2005 16:37:04 -0500
Subject: [fetter-devel] VC++ Support?
In-Reply-To: <437F5793.7010101@nyc.rr.com>
References: <437F5793.7010101@nyc.rr.com>
Message-ID: <d082aad0511191337n3c134334tfcf25c5a679be0b1@mail.gmail.com>

Yes. I was expecting to get the release out before my last round of
exams and projects, but that didn't happen and I had to stop working
on it for a couple of weeks. With those out of the way, I've resumed
work (and reading the mailing list --- my apologies to those who asked
questions that I didn't get around to answering !) and should get
something out by the 25th or 26th.

Sincerely,
    Rayiner Hashem

On 11/19/05, Kenny Tilton <ktilton at nyc.rr.com> wrote:
> Is there a new release of Verrazano on the way? I am especially anxious
> to get that VC++ support, as well as that more detailed control of which
> symbols get exported based on where they are found in the source tree.
>
> Someone asked about my cl-ftgl library and I realized it was in limbo
> waiting for both enhancements. I could always roll back to using C glue,
> but if a new Vzn is on the way I would prefer using that.
>
> --
> Kenny
>
> Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
>
> "I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it."
>     Elwood P. Dowd, "Harvey", 1950
>
>
>
> _______________________________________________
> fetter-devel mailing list
> fetter-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel
>