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

Richard Dale Richard_Dale at tipitina.demon.co.uk
Wed Jul 30 13:04:57 UTC 2003


On Wednesday 30 July 2003 15:27, Alexander Kellett wrote:
> (removing cc:, your on the list anyways)
>
> heya richard,
>
> On Wed, Jul 30, 2003 at 01:09:30PM +0100, Richard Dale wrote:
> > 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:
> >
> > <snip>
> >
> > 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.
>
> aah. eek. nice workaround :)
>
> > <snip>
> > It leaks memory at the moment, and doesn't do everything PerlQt does yet,
> > but looking good..
>
> what are the main things its currently missing?
> (duplication from my last email of course,
>  just skip anything you replied to already ;-)
>
> i was quite interested in doing some development
> of a kind of wierd idea i've had for a while.
> ruby is nice and dynamic, therefore, it would
> be quite possible to provide a ui allowing
> for completely visual inspection of the available
> classes, kind of like kdcop but for qt classes :)
>
> it would even be possible to store persistantly
> store creations of widgets done through the ui
> thus allowing project loading/saving, and even
> some kind of simplistic code generation system.
> in fact personally i don't think that creating
> something quite a bit better than designer would
> be an at all unrealistic goal for a single life
> time of work :)
Well, I'm afraid I'm a bit of a NeXT/Apple bore, but have a look at RubyCocoa 
they was the best ruby bindings I looked at when I was going round the net 
getting as much ruby/C interface code for ideas. It uses dynamic messaging in 
both Objective-C and Ruby. But you can use InterfaceBuilder with Ruby which 
is actually an 'instance composition tool'. It doesn't save a description 
aimed at generating code, it archives a network of real objects in the .nib 
file. Then unarchives them when you load the ui. I don't know exactly what 
RubyCocoa has done yet.

> this would rock, i'd finally be able to just
> code and not need to worry about how to do
> it ever again, i seem to remember you sharing
> this dream, so... :)
>
> oh that reminds me. how about a use of a
> delegator (i.e, coroutines, yield, whatever its
> called :)) for signal handlers? (i.e, SLOT's)
Currently it works just like PerlQt, by dynamically creating metaObjects, 
signal methods and overriding qt_invoke and qt_emit in ruby. It works fine, 
and needs to fit in with the C++ slots/signals, so I'm not sure if it could 
be changed to be more 'exotic'. Very Qt 3.x specific though. But it might be 
possible to layer some interesting ruby syntax on top, so it looks less like 
the C++ original.

> you ever on irc?, would be useful :)
Yes, I can be if we arrange a time, no problem..

-- Richard


More information about the Kde-bindings mailing list