[Kde-bindings] QVariant regression

Richard Dale rdale at foton.es
Sat Nov 21 20:01:37 UTC 2009


On Saturday 21 November 2009 05:20:57 pm David Palacio wrote:
> On Viernes 07 Agosto 2009 05:33:59 Richard Dale escribió:
> > On Thursday 06 August 2009 11:08:49 pm David Palacio wrote:
> > > On Jueves 06 Agosto 2009 16:43:12 David Palacio escribió:
> > > > This testcase stops working after the QVariant hack removal
> > > > (r1000416).
> > > >
> > > > Known affected application: Kaya.
> > >
> > > .....And the attachment
> >
> > OK, I can fix that one. But we really need to review all the cases where
> > a QVariant is passed to a method in the Qt and KDE apis. And that seems
> > to happen a lot.
> >
> > $ rbqtapi -mQVariant | grep '.*(.*QVariant' | wc -l
> > 170
> >
> > I was a bit annoyed when I found out what had be done, because there had
> >  been no public discussion at the time, no entry was added to the
> > ChangeLog and I didn't find out about it for a year.
> >
> > If you know what the 'munged method' scheme in the Smoke library is - ie
> > creating a simplified type signature for fast lookup by adding either
> > '#', '$' or '?' to the method name, you would know that a change which
> > effectively always made '#' and '$' the same, was a major change. And not
> > telling the maintainer about something like that is just really rude as
> > far as I am concerned. I'm sorry it had to be reverted, and is causing a
> > bit of pain by possibly breaking existing code.
> >
> > -- Richard
> >
> > _______________________________________________
> > Kde-bindings mailing list
> > Kde-bindings at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-bindings
> 
> A better testcase. It does not include model, sql and non-documented
>  methods. Or is the fix related to special casing each call in Ruby?
Thanks - the calls do need to be special cased at present, and I will try and 
go and make these test cases work.

I didn't like the 'hack fix', and for now I think special casing is best. For 
KDE 4.5 I think we can try to come up with a proper solution. I don't think we 
need to change the Smoke library as it has all the info needed, but at startup 
we need to dynamically generate all the possible new method call types that 
are possible from the C++ implicit constructor data.

-- Richard



More information about the Kde-bindings mailing list