[Kde-perl] Suspicious QWidget Initialization Behaviour

[Jonathan Yu]

Hi Chris:

On Tue, Aug 11, 2009 at 1:36 AM, Chris Burel<chrisburel at gmail.com> wrote:
> On Mon, Aug 10, 2009 at 8:47 PM, Gary Greene<greeneg at tolharadys.net> wrote:
>> On Monday 10 August 2009 8:10:11 pm Jonathan Yu wrote:
>>> Hi Chris:
>>>
>>> I'm not sure where this is happening, or perhaps if it's just a usage
>>> error. I'm creating a new object of a class that inherits from
>>> Qt::Widget. I've noticed if I do [the equivalent of]:
>>> Qt::Widget->new();
Note I wasn't actually doing that code. The actual code is a bit
hairy, but it's in the SVN repository for perlqt4. Notably it's this
code in Kde.pm (http://code.google.com/p/perlqt4/source/browse/trunk/Debconf/Element/Kde.pm)

This is the code I'm using in the constructor, which I believe is what
causes the core dump (since changing it around I get the Unknown
Method Combination Error):

sub NEW {
	shift->SUPER::NEW (@_[0..2]);
	this->{mytop} = undef;
}

Though in my working copy I changed that to:
sub NEW {
	shift->SUPER::NEW (shift);
	this->{mytop} = undef;
}

(This is because the old Qt::Widget constructor for Qt3 required more
parameters than Qt4, so I've updated it to match Qt4's.)

I even tried using:

shift->SUPER::NEW(shift, 0)

Where the first shift would be $class and the second shift would be
the $parent. The third parameter is just f, which is set to zero by
default.

I'm not sure if it's actually a bug somewhere, but still, having a
core dump is probably a Bad Thing if it can be avoided (using
parameter checking/exceptions).

>>>
>>> Then I get a core dump with the following backtrace:
>>>
>>> #0  QWidget::sizePolicy (this=0x0) at kernel/qwidget.cpp:8925
>>> 8925  kernel/qwidget.cpp: No such file or directory.
>>>       in kernel/qwidget.cpp
>
> I'm not sure exactly where your code is failing, so I'll outline a
> couple things that have to happen for subclasses to work.
>
> You can't (currently) call "MySubclass->new( @args )".  It's just
> "MySubclass( @args)".  This will be routed to MySubclass::NEW(
> $classname, @args);
> Tell Qt what you're subclassing from by placing "use Qt::isa qw(
> ParentClass )" in your subclass's module.
> You have to implement a NEW() method in your subclass.  The NEW()
> method must call $class->SUPER::NEW();
> Every method call made from the subclass should be made on the "this"
> object.  This is the main deviation from PerlQt3.
>
> For example:
> #!/usr/bin/perl
>
> package Foo;
>
> use strict;
> use warnings;
> use Qt;
> use Qt::isa qw( Qt::Widget );
>
> sub NEW {
>    my ( $class, $parent ) = @_;
>    $class->SUPER::NEW( $parent );  # not Qt::Widget->new( $parent )
>    this->resize( 500, 500 );    # not just resize( 500, 500 );
> }
>
> package main;
>
> use strict;
> use warnings;
> use Qt;
> use Foo;
>
> sub main {
>    my $app = Qt::Application( \@ARGV );
>    my $widget = Foo( undef );    # not Foo->new
>    $widget->show();
>    return $app->exec();
> }
>
> main();
>
>> Dunno if this still works in PerlQt4, did in 3....
>> Another useful aspect is doing the following:
>>
>> use Qt::debug qw| CHANNEL |;
>>
>> Where CHANNEL is one of:
>>
>> ambiguous, verbose, calls, autoload, gc, virtual, all
>>
> These are still present in PerlQt4, but have to be enabled at compile
> time.  Maybe I'm mistaken, but I figured that stuff was only useful to
> people developing the bindings, and not to normal users of the
> bindings.  So I thought it was silly to have a bunch of "if( debug )"
> tests when running normal code.
> If you want to enable those debug messages, specify -DDEBUG while compiling.
> On that note, is there a better/more standard define to use for those
> sort of debugging messages?
>
> --Chris
>