[Kde-bindings] Re: Custom properties on QObjects defined in qtruby

[Richard Dale]

On Thursday, May 19, 2011 02:25:43 PM Sven Moritz Hallberg wrote:
> On 04/14/2011 10:09 PM, Sven Moritz Hallberg wrote:
> > i've still got a bug here where setting the QVariant property from ruby
> > doesn't work. it looks like it's some unpacking issue with the
> > Qt::Variants. i.e. as if something looks at the types in
> > 
> >     dings.setProperty("stuff", Qt::Variant.new("test"))
> > 
> > and doesn't call qt_metacall because it's expecting to see something of
> > the form
> > 
> >     Qt::Variant.new(Qt::Variant.new("test"))
> > 
> > but i can't pass that because the constructor avoids nesting.
> 
> sorry for the long silence, some other priorities intervened...
> i'm attaching my current patch against the latest qtruby from git
> along with a test program that exhibits some problems i can't track down.
> it defines a class with two properties, one of type QString, another of
> QVariant. it tries to assign values to these in a variety of ways and to
> read them back in various ways. it SHOULD print the series of test strings
> going from "test1" to "test5" twice, interleaved with some diagnostics in
> parenthesis. like this:
> 
>     (blablabla)
>     "test1"
>     (blablabla)
>     "test2"
>     .
>     .
>     .
>     "test5"
>     (blablabla)
>     "test1"
>     .
>     .
>     .
>     "test5"
> 
> this is the actual output:
> 
>     (initial value "test1")
>     "test1"
>     (writing "test2" -> true)
>     "test2"
>     (setting "test3" -> true)
>     "test3"
>     (assigning "test5")
>     "test5"
>     (initial value "test1")
>     "test1"
>     (writing "test2" -> false)
>     "test1"
>     (setting "test3" -> false)
>     "test1"
>     (Foo#changeProp(#<Qt::Variant:0x7f983abb1fa0 typeName=QString>))
>     (Foo#changeProp("test4"))
>     (setting "test4" -> nil)
>     "test4"
>     /usr/local/lib/site_ruby/1.8/Qt/qtruby4.rb:2435: [BUG] Segmentation
> fault ruby 1.8.7 (2010-06-23 patchlevel 299) [x86_64-linux]
> 
>     Aborted
> 
> "test4" is missing from the first run because i commented it out. left in,
> it produces some memory error from glibc:
> 
>     (setting "test3" -> true)
>     "test3"
>     (setting "test4" -> nil)
>     qt3.rb:43: undefined method `value' for "test4":String (NoMethodError)
>     *** glibc detected *** ruby: free(): invalid pointer:
> 0x00007fff54bd2cb0 ***
> 
> the next obvious problem is the segfault after "test4" in the second run. i
> have a stack trace from gdb and it points to where the 'qt_writeprop'
> function extracts the value from the passed QVariant.
> 
> actually, these are just annoyances, though, that i encountered on the way
> trying to nail down an actual usage problem: i can't assign to the QVariant
> property through the metacall facility:
> 
>     (initial value "test1")
>     "test1"
>     (writing "test2" -> false)
>     "test1"
>     (setting "test3" -> false)
>     "test1"
> 
> note that it works with the QString property. also note that when reading
> the QVariant property via meta calls, i do get a Qt::Variant wrapped in a
> Qt::Variant (contrary to what Qt::Variant.new will allow). cf. occurances
> of ".value.value" in the code.
> 
> there is definately something weird going on with these Variants, i just
> can't put my finger on it. and it is a problem on the ruby side of things:
> writing and assigning the QVariant property from a QML test program works
> flawlessly.
> 
> oomph, sorry for the wall of text!
> 
> 
> -Sven
> 
> PS. technically, the patch is (c) my employer. alas, we'd very much like to
> see it upstream, so it goes as "do what you want, no warranties". ;)
Yes, I will try and commit the patch soon - thanks very much for some 
excellent work!

> PPS. seeing that work has started on a new version of qtruby, which i
> haven't had time to look at, yet, i hope this can be ported over!
In QtRuby 3.x all the slots and signals and QMetaObject creation code is 
written in C++, and so it will be a matter of rewriting the code rather than 
porting. But I think QtRuby should have properties like you've implemented 
them, and we should get them working the same way in both the 2.x and 3.x 
versions. 

So I'll try and debug your patch and see what is going on so that we can 
commit it for the next KDE release. I'm not sure yet whether QtRuby 3.x will 
be ready for the next KDE release, and maybe it would be a good idea to carry 
on with QtRuby 2.x for as long as it takes to get the new 3.x version really 
solid.

-- Richard