[Kde-bindings] const_missing method in ruby 1.8

[Richard Dale]

On Tuesday 05 August 2003 09:39, Alexander Kellett wrote:
> On Tue, Aug 05, 2003 at 08:57:34AM +0100, Richard Dale wrote:
> > From the ruby 1.8 release notes:
> >
> > ': constants lookup
> >
> >   improved at the performance of searching by using an internal hash
> >   table.
> >
> >   calls const_missing method of the class/module, if constant is not
> >   found in the look up path.'
> >
> > So it does look as though it will possible to trap references to to
> > const_missing for constants in QtRuby. Then the Qt::Widget::MYCONST
> > syntax can be used rather than Qt::Widget.MYCONST.
>
> yay for 1.8 :)
Yes, this was the only thing I can remember that I couldn't get to work, so 
great.

> was trying to hack on this as i noticed the same
> thing, but, i need to figure out exactly how
> the current bindings work first :)
>
> but, quick question nevertheless, would this
> be modifications to Qt.rb or Qt.cpp?, i didn't
> really understand the do_method_missing. i'll
> try to read more code tonight. haven't read
> all that much up till now.
It probably won't involve a change to do_method_missing in Qt.rb. It might 
just be a matter of adding this in Qt.cpp, Init_Qt():

    rb_define_singleton_method(qt_base_class, "const_missing", (VALUE (*) 
(...)) class_method_missing, -1);
    rb_define_singleton_method(qt_module, "const_missing", (VALUE (*) (...)) 
module_method_missing, -1);
    rb_define_method(qt_base_class, "const_missing", (VALUE (*) (...)) 
method_missing, -1);

Just add three new overrides for 'const_missing' which point to the same C 
functions as the three 'method_missing' equivalents.

> erm. slightly OT now.
>
> also. i'm having problems with iterators as
> return types. example attached. this doesn't
> appear to exist at all in the smoke bindings.
> yet i notice that the perlqt docs say that
> while templates aren't bound, templated classes
> are, or, thats what i understood from it in
> any case :)
>
> so, in qcanvas.h is see:
>    class QCanvasItemList : public QValueList<QCanvasItem*>;
>
> then. in smoke
>    smokedata.cpp:  { "QCanvasItemList", 0, Smoke::t_voidp | Smoke::tf_stack
> },     //44
>
> and grep QCanvasItemList turns up nothing else but for return types
>
> so. the error
>    builder.rb:17: [BUG] Cannot handle 'QCanvasItemList' as return-type of
> QCanvas::collisions is really quite understandable.
> though a nice error message would be nicer, which
> brings me to another tangent.
I think it would be a good idea to try the same thing in PerlQt, and see how 
its error messages come out.

> i'm guessing that some sort of generic base QValueList[Iterator]
> object handler needs to be created?, or, is there a minor
> bug in the bindings generation that stops this case maybe?
>
> i'm guessing its also not possible to use it as a parameter
> therefore, which is pretty limiting as a large number of
> functions use QPtrLists's, QValueList's etc.
We'd need specific marshallers for each concrete instance of a QValueList I 
think, in handlers.cpp. Here are the existing marshallers, so there are some 
QValueList ones - we would need some more like that for QCanvasItemList etc.

TypeHandler Qt_handlers[] = {
    { "QString", marshall_QString },
    { "QString&", marshall_QString },
    { "QString*", marshall_QString },
    { "QCString", marshall_QCString },
    { "QCString&", marshall_QCString },
    { "QCString*", marshall_QCString },
    { "QStringList", marshall_QStringList },
    { "QStringList&", marshall_QStringList },
    { "QStringList*", marshall_QStringList },
    { "int&", marshall_intR },
    { "int*", marshall_intR },
    { "bool&", marshall_boolR },
    { "bool*", marshall_boolR },
    { "char*", marshall_charP },
    { "char**", marshall_charP_array },
    { "uchar*", marshall_ucharP },
    { "QRgb*", marshall_QRgb_array },
    { "QUObject*", marshall_voidP },
    { "const QCOORD*", marshall_QCOORD_array },
    { "void", marshall_void },
    { "QValueList<int>", marshall_QValueListInt },
    { "QValueList<int>*", marshall_QValueListInt },
    { "QValueList<int>&", marshall_QValueListInt },
    { 0, 0 }
};
> okay, back to the tangent. error handling currently code
> such as canvas.setBrush(Qt::Color.new(r,g,b)) will simply
> bomb out with little information as brush is expecting
> a QBrush, not a QColor. as i'm guessing
I think that could be improved - I haven't put much thought into better error 
handling really - sadly the project came together with excessive speed :)

> this pqtsh thing looks really nice. i'd like to
> do something like this in ruby. i wonder if it
> uses anything more than perl's introspection or
> if PerlQt provides a sort of smoke perl binding?
I hadn't heard of that

> any ideas?
>
> later,
> Alex
>
> p.s: if anyone has a PerlQt checkout, i really
>      could use it, as i can't get anything
>      whatsoever from sourceforge cvs  :(
I just downloaded the PerlQt-3.006.tar.gz tarball, I didn't try to get 
anything from the cvs.

-- Richard