[Kde-bindings] Crash when using the valued returned by KDE::EncodingFileDialog.get_save_file_name_and_encoding in korundum

[Richard Dale]

On Monday 28 December 2009 03:39:14 pm Stefano Crocco wrote:
> It seems there's something wrong with the value returned by
> KDE::EncodingFileDialog.get_save_file_name_and_encoding in korundum. The
> dialog itself seems to work correctly, but when I try to access the
>  returned object, I get an exception. Here's an example code:
> 
> require 'korundum4'
> 
> data = KDE::AboutData.new "kruby", "", KDE::ki18n("KRuby"), "0.0.39",
>     KDE.ki18n('A Ruby IDE written in Ruby')
> KDE::CmdLineArgs.init ARGV, data
> a = KDE::Application.new
> 
> res = KDE::EncodingFileDialog.get_save_file_name_and_encoding 'UTF-8',
> __FILE__, '', nil, KDE.i18n('Save File')
> p res.encoding
> 
> The exact error I get when running the above code (with ruby 1.9.1p243) is:
> 
> /usr/lib/ruby19/site_ruby/1.9.1/Qt/qtruby4.rb:2603:in `do_method_missing':
> undefined method `name' for nil:NilClass (NoMethodError)
> 	from /usr/lib/ruby19/site_ruby/1.9.1/Qt/qtruby4.rb:2606:in
> `do_method_missing'
> 	from /usr/lib/ruby19/site_ruby/1.9.1/Qt/qtruby4.rb:2606:in
> `do_method_missing'
> 	from /usr/lib/ruby19/site_ruby/1.9.1/Qt/qtruby4.rb:2606:in
> `do_method_missing'
> 	from /usr/lib/ruby19/site_ruby/1.9.1/Qt/qtruby4.rb:2606:in
> `do_method_missing'
> 	from prova.rb:10:in `method_missing'
> 	from prova.rb:10:in `<main>'
> 
> The same happens if I try res.file_names or res.URLs. I'm not sure if this
>  is related, but if I write
> 
> p res.class
> 
> I get KDE::dingFileDialog::Result (of course, I'd expect
> KDE::EncodingFileDialog::Result instead).
OK, i've just tried this and I get the same result - I'm not sure why yet.

> By the way, does anyone know whether the bug about KDE::SharedConfig#group
>  not working (http://lists.kde.org/?l=kde-bindings&m=125561411924191&w=2)
>  has been fixed or is going to be fixed before the release of KDE 4.4? I
>  saw a mail on the list
>  (http://lists.kde.org/?l=kde-bindings&m=125804672228574&w=2) from which it
>  seems the source of the problem had been found out. However, at least
>  until about ten days ago (when I last tried building smokde and korundum
>  from svn), it hasn't been fixed. According to the KDE release schedule,
>  the bindings freeze for KDE 4.4 is just a matter of days now (the 5th of
>  January). I truly hope this bug will be fixed before then (or before KDE
>  4.4 is released, at any rate), because it makes it impossible to use KDE
> configuration system (of course, unless there's a way I don't know of which
> allows to obtain configuration options without using
>  KDE::SharedConfig#group).
Yes, I will try and fix this bug. I think it was caused by QtRuby not working 
with methods overloaded on just const-ness. 

As far as I know we can carry on fixing things right up until the KDE final 
release (ie after 5th Jan). 

I am having trouble with keeping up with the KDE 4.4 release schedule to be 
honest. Before I could do anything to QtRuby I needed to split up the Smoke 
libraries, and get the JavaScript JSmoke bindings sufficiently complete to be 
able to copy the much improved design into QtRuby/Korundum. That took quite a 
lot of time, but is now done. The improved JSmoke overloaded method resolution 
code would fix the above problem properly, but now I've run out of time I might 
have to do some hacks to get it fixed in Korundum for KDE 4.4

I have got about half-way through a major re-factor of QtRuby, but I think it 
is too late to get that into the KDE 4.4 branch. The JSmoke code is much 
tidier, although functionally equivalent to the QtRuby code - it does as much 
by and large, but looks much simpler (see http://gitorious.org/qtscript-smoke 
in the src directory for the tidier code).

Over six and a half years the QtRuby code has just got more and more untidy - 
it is badly in need of a re-factor, and it is very difficult to hurry that for 
an arbitrary release date like KDE 4.4. My hope is that after the refactor it 
will be easier to understand, and people other than me will be able to fix 
things directly in the svn. Then everything won't depend quite so much on me. 
People must understand the existing code as they send in patches, but I don't 
even always get time to review and commit the patches quickly enough.

-- Richard