[Kde-bindings] clib test app not working...

[Richard Dale]

On Wednesday 24 March 2004 17:36, Ashley Winters wrote:
> --- Richard Dale <Richard_Dale at tipitina.demon.co.uk> wrote:
> > > Would it be possible to build new, better C bindings automatically
> > > with kalyptus ?
> >
> > Yes it wouldn't be very difficult to generate ones which didn't need
> > manual
> > edits. Ashley has suggested a library api called 'Mirror' for
> > languages which
> > are too static to use Smoke.
>
> You've effectively killed Mirror with your proxy bindings.
>
> > I've personally got no ethusiasm for C
> > bindings
> > at all though. No one actually wants to do GUI programming in C, they
> > are
> > only for implementing bindings for other languages. And Smoke does
> > that so
> > much better that I can't see the point.
>
> This is very true... anyone who genuinely wants to use C for GUI
> programming is going to be offended by even our best efforts to
> /generate/ a usable Qt interface in it.
>
> Everyone else wants C bindings for P/Invoke or JNI style function
> calling. Since most languages are going out of their way to implement
> transparent RPC mechanisms, we can just hijack those for Smoke
> interfaces.
In the .NET framework there are MarshalByRefObject's which are intended for 
RPC purposes, which my example QFont.cs class used. But MS's intention is for 
the 'ContextBoundObject' to be the basis of component frameworks (or KDE 
language bindings in our case). I've only recently been playing with C#/mono 
0.30, and I found the RealProxy feature didn't work without a minor one line 
fix, and ContextBoundObject weren't implemented at all. If Microsoft thinks 
this class is the basis of their component strategy, how come it isn't even 
implemented yet in Mono? 

> Here is the Smoke framework in a nutshell:
>
> 1. API parser (kalyptus currently, gcc in smoke v2)
> 2. Code generator (CxxToSmoke in kalyptus, RDF analyzer in smoke v2)
> 3. Runtime library (the "yacc output" Richard referred to earlier)
>
> The runtime portion of Smoke is quite good, and I would put it up
> against anyone else's language bindings. 
Yes I would agree but I don't think you've explained why - not that it is 
easy. I keep this URL:

http://z.iwethey.org/forums/render/content/show?contentid=110693

They discuss the difference between languages and programming communities who 
see Object Oriented programming in two different ways. FOO vs. MOO - see the 
link for the full explanation. Very sensible viewpoints: Jim Weinrich, ruby 
and Todd Blanchard Smalltalk/Objective-C.

The Qt/KDE C++ api is FOO even with the help of the moc. But Smoke turns FOO 
into MOO (ie alchemy, lead into gold :) ).

> The glue portion of the
> runtime needs work, since we want to have separate runtime libs for Qt
> and KDE. The specific (cryptic) implementations of 1 and 2 could easily
> be changed and improved without changing the runtime interface.
>
> I'm hoping to make the code-generator easy to customize using XML
> information in smoke v2. That way, we could distribute a definitive
> Qt/KDE API. For example:
>
> <rdf:RDF
>     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>     xmlns:C="http://rdf.kde.org/lang/C++/">
>
>   <rdf:Description
>    rdf:about="http://rdf.kde.org/lib/qt/3.3/kernel#
>               QPainter::drawCubicBezier(const+QPointArray&,+int)"
>    C:PPifndef="QT_NO_BEZIER">
>
> </rdf:RDF>
>
> That would modify the generated code to automatically #ifndef the
> binding code for QPainter::drawCubicBezier. An entire file of such
> customizations would be possible, thereby allowing distribution of
> pre-generated code customized to a specific release of Qt/KDE, but
> still allowing for variations in the base compile options.
I think the RDF api vocabulary is a great idea, and would be useful 
immediately, even before basing Smoke v2 on it. Then we could start to 
prototype uses.

-- Richard