[Kde-bindings] Re: kdebindings/qtruby (silent)

Richard Dale Richard_Dale at tipitina.demon.co.uk
Wed Jul 30 12:09:30 UTC 2003


Hi Alex

On Wednesday 30 July 2003 14:22, Alexander Kellett wrote:
> On Wed, Jul 30, 2003 at 01:11:47PM +0200, Richard Dale wrote:
> > CVS commit by rdale:
> > Directory /home/kde/kdebindings/qtruby added to the repository
>
> yay!, you rock!
>
> /me updates to check if its got method lookup thats okay
> for ambigious type overides :) (no idea how to say that with correct lingo)
>
> btw. 0.6 tarball worked well for me other than above thing
> which was kind of a show stopper for going any further
> in my app :(
Yes - it all came together after I fixed that overloaded method resolution 
properly (by copying the code from PerlQt). The other interesting problem I 
needed to get round was with constructors - here is the comment from the 
code:

/*

class LCDRange < Qt::Widget

	def initialize(s, parent, name)
		super(parent, name)
		init()
		...

For a case such as the above, the QWidget can't be instantiated until
the initializer has been run up to the point where 'super(parent, name)'
is called. Only then, can the number and type of arguments passed to the
constructor can be known. However, the rest of the intializer
can't be run until 'self' is a proper T_DATA object with a wrapped C++
instance.

The solution is to run the initialize code twice. First, only up to the
'super(parent, name)' call, where the QWidget would get instantiated in
initialize_qt(). And then continue_new_instance() jumps out of the
initializer returning the wrapped object as a result.

The second time round 'self' will be the wrapped instance of type T_DATA,
so initialize() can be allowed to proceed to the end.
*/

It leaks memory at the moment, and doesn't do everything PerlQt does yet, but 
looking good..

-- Richard



More information about the Kde-bindings mailing list