Nabble - kde-perl

Re: PerlQt as LGPL?

2009-10-06T19:00:56Z

On Tuesday 06 October 2009 11:38:42 am Richard Dale wrote:

> On Tuesday 06 October 2009 07:05:18 pm Eric Wilhelm wrote:
> > Hello Germain and Ashley,
> >
> > (sending this to the list since germain@... bounced)
> >
> > Now that Nokia has released Qt 4.5 as LGPL, would it be possible to
> > relicense the Perl bindings as LGPL?
>
> Ashley Winters and David Faure have given permission to relicense PerlQt
> and the language bindings derived from it under the LGPL. We didn't hear
> from Germain, but assumed he didn't object. So QtRuby, Wt::Ruby and Qyoto
> are already under the LGPL license, and as far as I know PerlQt can be the
> same.
>
> -- Richard
> _______________________________________________
> Kde-perl mailing list
> Kde-perl@...
> https://mail.kde.org/mailman/listinfo/kde-perl
>

Working on getting explicit approval from Germain.
--
Gary L. Greene, Jr.
Sent from: skuld
7:00pm up 4 days 19:24, 5 users, load average: 0.51, 0.23, 0.14
==========================================================================
Developer and Project Lead for the AltimatOS open source project
Volunteer Developer for the KDE open source project
See http://www.altimatos.com/ and http://www.kde.org/ for more information
==========================================================================

Please avoid sending me Word or PowerPoint attachments.
_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Re: PerlQt as LGPL?

2009-10-06T11:38:42Z

On Tuesday 06 October 2009 07:05:18 pm Eric Wilhelm wrote:
> Hello Germain and Ashley,
>
> (sending this to the list since germain@... bounced)
>
> Now that Nokia has released Qt 4.5 as LGPL, would it be possible to
> relicense the Perl bindings as LGPL?
Ashley Winters and David Faure have given permission to relicense PerlQt and
the language bindings derived from it under the LGPL. We didn't hear from
Germain, but assumed he didn't object. So QtRuby, Wt::Ruby and Qyoto are
already under the LGPL license, and as far as I know PerlQt can be the same.

-- Richard
_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

PerlQt as LGPL?

2009-10-06T11:05:18Z

Hello Germain and Ashley,

(sending this to the list since germain@... bounced)

Now that Nokia has released Qt 4.5 as LGPL, would it be possible to
relicense the Perl bindings as LGPL?

Thanks,
Eric
--
"Time flies like an arrow, but fruit flies like a banana."
--Groucho Marx
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

SUPER, installsuper, XS_super

2009-10-03T01:01:05Z

Hi all,

Another tail end of an irc conversation with Chris...

It appears that XS_super() and the XS installsuper() are not needed.

In Qt/isa.pm

# This hash is used to get an object blessed to the right thing, so that
# when we call SUPER(), we get this blessed object back.
my $duper = ${$caller.'::_INTERNAL_STATIC_'}{'SUPER'} = bless {}, " $caller";
# Qt::_internal::installsuper($caller);# unless defined &{ $caller.'::SUPER' };
{
my $sub = sub {$duper};
no strict 'refs';
*{"$caller\::SUPER"} = $sub;
}

And really this %MyClass::_INTERNAL_STATIC_ isn't needed either
AFAICT.

But ultimately, I think the object->SUPER->method shouldn't be
required (and doesn't that lose the object data anyway?) if the
AUTOLOAD can be made to see SUPER::method(). I suspect that
the current scheme might actually break down at two levels
deep anyway but that's all I've got for tonight.

--Eric
--
"It works better if you plug it in!"
--Sattinger's Law
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Qt::isa Deep recursion problem

2009-10-02T21:34:13Z

(RESENT from my subscribed address)

Hi Chris,

What is this for? I see you added it in r245.

push @{ $caller . '::SUPER::ISA' }, $caller;

I just removed that in r403.

On perl 5.8.8, this causes recursion because it's somehow equivalent to
calling main::SUPER->new.

perl -e 'use warnings; use strict;
sub bar::new {warn "hi"}
@main::SUPER::ISA = qw(main);
package main; our @ISA = qw(bar);
sub new {shift->SUPER::new(@_)};
main->new'

--Eric
--
To a database person, every nail looks like a thumb.
--Jamie Zawinski
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Qt::isa Deep recursion problem

2009-10-02T21:28:54Z

Hi Chris,

What is this for? I see you added it in r245.

push @{ $caller . '::SUPER::ISA' }, $caller;

I just removed that in r403.

On perl 5.8.8, this causes recursion because it's somehow equivalent to
calling main::SUPER->new.

perl -e 'use warnings; use strict;
sub bar::new {warn "hi"}
@main::SUPER::ISA = qw(main);
package main; our @ISA = qw(bar);
sub new {shift->SUPER::new(@_)};
main->new'

--Eric
--
To a database person, every nail looks like a thumb.
--Jamie Zawinski
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

PerlQt with Perl 5.10

2009-08-13T03:10:04Z

Thanks for the quick replies.

I found this post:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481642

which gives a workaround for this problem. Simply comment the line

use Qt::debug();

in Qt.pm (either before or after installation) and everything works. I am not sure what the consequences are but for now it seems to work.

Cheers
Zaher

kde-perl-request@... wrote:

> Message: 1
> Date: Wed, 12 Aug 2009 13:15:37 +0000 (GMT)
> From: Zaher Salman <zaher_salman@...>
> Subject: [Kde-perl] (no subject)
> To: kde-perl@...
> Message-ID: <972249.35097.qm@...>
> Content-Type: text/plain; charset=utf-8
>
> Hi,
>
> I am trying to compile perl-qt with perl 5.10. Everything goes well including the install, but then when I generate an application (using puic or from the examples) I get the following error
>
> --- No method to call for :
> QApplication::new('Qt::Applic...', ARRAY(0x806a4a8))
> at /usr/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi/Qt.pm line 469.
>
> Any ideas why?
>
> By the way, is perl-qt still being actively developed?
>
> thanks
> Zaher
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 12 Aug 2009 09:45:00 -0400
> From: Jonathan Yu <jonathan.i.yu@...>
> Subject: Re: [Kde-perl] (no subject)
> To: kde-perl@...
> Message-ID:
> <d1b732a70908120645y940137aof94feeb833707d37@...>
> Content-Type: text/plain; charset=UTF-8
>
> Hi:
>
> On Wed, Aug 12, 2009 at 9:15 AM, Zaher Salman<zaher_salman@...> wrote:
>> Hi,
>>
>> I am trying to compile perl-qt with perl 5.10. Everything goes well including the install, but then when I generate an application (using puic or from the examples) I get the following error
>>
>> --- No method to call for :
>> ? ? ? ?QApplication::new('Qt::Applic...', ARRAY(0x806a4a8))
>> at /usr/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi/Qt.pm line 469.
>>
>> Any ideas why?
> Perhaps you should be using: QApplication(...) -- ie, without using
> ::new like that. Though without knowing what version of the Qt
> bindings you're using, it's hard to tell if that's the correct syntax.
> Still, based on the PerlQt3 bindings, the constructors look like:
>
> Qt::Application(...)
> or
> Qt::Application->new(...)
>> By the way, is perl-qt still being actively developed?
> It depends on which version of perlqt you're using. There are many,
> and many of them are abandoned.
>
> The most promising one and most actively maintained one right now is
> on Google Code: http://code.google.com/p/perlqt4/ and is a candidate
> for inclusion in the kdebindings package.
>> thanks
>> Zaher
>>
>>
>>
>>
>>
>> _______________________________________________
>> Kde-perl mailing list
>> Kde-perl@...
>> https://mail.kde.org/mailman/listinfo/kde-perl
>>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 12 Aug 2009 07:42:41 -0700
> From: Gary Greene <greeneg@...>
> Subject: Re: [Kde-perl] (no subject)
> To: kde-perl@...
> Message-ID: <200908120742.49139.greeneg@...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Wednesday 12 August 2009 06:45:00 am Jonathan Yu wrote:
>> Hi:
>>
>> On Wed, Aug 12, 2009 at 9:15 AM, Zaher Salman<zaher_salman@...>
> wrote:
>>> Hi,
>>>
>>> I am trying to compile perl-qt with perl 5.10. Everything goes well
>>> including the install, but then when I generate an application (using
>>> puic or from the examples) I get the following error
>>>
>>> --- No method to call for :
>>> ?? ?? ?? ??QApplication::new('Qt::Applic...', ARRAY(0x806a4a8))
>>> at /usr/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi/Qt.pm line
>>> 469.
>>>
>>> Any ideas why?
>> Perhaps you should be using: QApplication(...) -- ie, without using
>>
>> ::new like that. Though without knowing what version of the Qt
>>
>> bindings you're using, it's hard to tell if that's the correct syntax.
>> Still, based on the PerlQt3 bindings, the constructors look like:
>>
>> Qt::Application(...)
>> or
>> Qt::Application->new(...)
>>
>>> By the way, is perl-qt still being actively developed?
>> It depends on which version of perlqt you're using. There are many,
>> and many of them are abandoned.
>>
>> The most promising one and most actively maintained one right now is
>> on Google Code: http://code.google.com/p/perlqt4/ and is a candidate
>> for inclusion in the kdebindings package.
>>
>>> thanks
>>> Zaher
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Kde-perl mailing list
>>> Kde-perl@...
>>> https://mail.kde.org/mailman/listinfo/kde-perl
>> _______________________________________________
>> Kde-perl mailing list
>> Kde-perl@...
>> https://mail.kde.org/mailman/listinfo/kde-perl
>
> If this is in regards to the 3.009b2 release of the bindings, they are no
> longer actively maintained. At this point the 3.009b2 bindings have NOT been
> vetted for compile problems with 5.10, and likely won't be as PerlQt4 is the
> preferred direction for the project at this point (being that Qt3 is EOL).
>

_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Re: (no subject)

2009-08-12T07:42:41Z

On Wednesday 12 August 2009 06:45:00 am Jonathan Yu wrote:
> Hi:
>
> On Wed, Aug 12, 2009 at 9:15 AM, Zaher Salman<zaher_salman@...>
wrote:

> > Hi,
> >
> > I am trying to compile perl-qt with perl 5.10. Everything goes well
> > including the install, but then when I generate an application (using
> > puic or from the examples) I get the following error
> >
> > --- No method to call for :
> > Â Â Â Â QApplication::new('Qt::Applic...', ARRAY(0x806a4a8))
> > at /usr/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi/Qt.pm line
> > 469.
> >
> > Any ideas why?
>
> Perhaps you should be using: QApplication(...) -- ie, without using
>
> ::new like that. Though without knowing what version of the Qt
>
> bindings you're using, it's hard to tell if that's the correct syntax.
> Still, based on the PerlQt3 bindings, the constructors look like:
>
> Qt::Application(...)
> or
> Qt::Application->new(...)
>
> > By the way, is perl-qt still being actively developed?
>
> It depends on which version of perlqt you're using. There are many,
> and many of them are abandoned.
>
> The most promising one and most actively maintained one right now is
> on Google Code: http://code.google.com/p/perlqt4/ and is a candidate
> for inclusion in the kdebindings package.
>
> > thanks
> > Zaher
> >
> >
> >
> >
> >
> > _______________________________________________
> > Kde-perl mailing list
> > Kde-perl@...
> > https://mail.kde.org/mailman/listinfo/kde-perl
>
> _______________________________________________
> Kde-perl mailing list
> Kde-perl@...
> https://mail.kde.org/mailman/listinfo/kde-perl

If this is in regards to the 3.009b2 release of the bindings, they are no
longer actively maintained. At this point the 3.009b2 bindings have NOT been
vetted for compile problems with 5.10, and likely won't be as PerlQt4 is the
preferred direction for the project at this point (being that Qt3 is EOL).

--
Gary L. Greene, Jr.
Sent from: peorth.tolharadys.net
07:39:56 up 100 days, 6 min, 4 users, load average: 0.83, 0.77, 0.62
==========================================================================
Developer and Project Lead for the AltimatOS open source project
Volunteer Developer for the KDE open source project
See http://www.altimatos.com/ and http://www.kde.org/ for more information
==========================================================================

Please avoid sending me Word or PowerPoint attachments.

_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

signature.asc (196 bytes) Download Attachment

Re: (no subject)

2009-08-12T06:45:00Z

Hi:

On Wed, Aug 12, 2009 at 9:15 AM, Zaher Salman<zaher_salman@...> wrote:
> Hi,
>
> I am trying to compile perl-qt with perl 5.10. Everything goes well including the install, but then when I generate an application (using puic or from the examples) I get the following error
>
> --- No method to call for :
> QApplication::new('Qt::Applic...', ARRAY(0x806a4a8))
> at /usr/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi/Qt.pm line 469.
>
> Any ideas why?
Perhaps you should be using: QApplication(...) -- ie, without using
::new like that. Though without knowing what version of the Qt
bindings you're using, it's hard to tell if that's the correct syntax.
Still, based on the PerlQt3 bindings, the constructors look like:

Qt::Application(...)
or
Qt::Application->new(...)
>
> By the way, is perl-qt still being actively developed?
It depends on which version of perlqt you're using. There are many,
and many of them are abandoned.

The most promising one and most actively maintained one right now is
on Google Code: http://code.google.com/p/perlqt4/ and is a candidate
for inclusion in the kdebindings package.

>
> thanks
> Zaher
>
>
>
>
>
> _______________________________________________
> Kde-perl mailing list
> Kde-perl@...
> https://mail.kde.org/mailman/listinfo/kde-perl
>

_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

(no subject)

2009-08-12T06:15:37Z

Hi,

I am trying to compile perl-qt with perl 5.10. Everything goes well including the install, but then when I generate an application (using puic or from the examples) I get the following error

--- No method to call for :
QApplication::new('Qt::Applic...', ARRAY(0x806a4a8))
at /usr/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi/Qt.pm line 469.

Any ideas why?

By the way, is perl-qt still being actively developed?

thanks
Zaher

_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Re: Suspicious QWidget Initialization Behaviour

2009-08-11T07:14:46Z

Hi Chris:

On Tue, Aug 11, 2009 at 1:36 AM, Chris Burel<chrisburel@...> wrote:
> On Mon, Aug 10, 2009 at 8:47 PM, Gary Greene<greeneg@...> 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
>

_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Re: Suspicious QWidget Initialization Behaviour

2009-08-10T23:11:16Z

On Monday 10 August 2009 10:36:52 pm Chris Burel wrote:

> > 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?

I found this VERY useful when dealing with code paths not working the way I
wanted. Admittedly this was because the PerlKDE3 code is missing a number of
important classes (KXMLGuiFactory for one....), but this was very handy in
being able to access the call stack during development of an app.

With regard to what would be "better" would imo, to change that from having to
import a whole new module to activate it to changing it to be a configuration
option to the main module as it's being used:

use Qt qw(debug: CHANNEL);

This way Qt::debug could be redone so it can be used to register new debug
CHANNELS for the app. This also fits better with a number of modules out there
that do much the same re the use of the use parameter for loading modules.

Just my $0.02

>
> --Chris
> _______________________________________________
> Kde-perl mailing list
> Kde-perl@...
> https://mail.kde.org/mailman/listinfo/kde-perl
>

_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Re: Suspicious QWidget Initialization Behaviour

2009-08-10T22:36:52Z

On Mon, Aug 10, 2009 at 8:47 PM, Gary Greene<greeneg@...> 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();
>>
>> 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
_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Re: Suspicious QWidget Initialization Behaviour

2009-08-10T20:47:13Z

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();
>
> 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
> (gdb) bt full
> #0 QWidget::sizePolicy (this=0x0) at kernel/qwidget.cpp:8925
> No locals.
> #1 0xb7a6a938 in xcall_QWidget (xi=<value optimized out>, obj=0x0,
> args=0x9bb7d08) at /home/jon/kdebindings/build/smoke/qt/x_20.cpp:4820
> No locals.
> #2 0xb7bd5153 in PerlQt::MethodCall::callMethod (this=0xbf9b1860)
> at src/marshall_types.h:132
> method = (Smoke::Method *) 0xb7b2feac
> fn = (void (*)(short int, void *,
> Smoke::StackItem *)) 0xb7a69c40 <xcall_QWidget(short, void*,
> Smoke::StackItem*)>
> ptr = (void *) 0x0
> callreturn = {<PerlQt::MethodReturnValueBase> = {<Marshall> = {
> _vptr.Marshall = 0xbf9b1668}, _smoke = 0x80abc27, _methodIndex =
> -31492, _stack = 0x8f98548, _retval = 0xb7f32ff4}, <No data fields>}
> #3 0xb7bd1f38 in PerlQt::MethodCallBase::next (this=0xbf9b1860)
> at src/marshall_types.cpp:387
> oldcur = -1
> #4 0xb7bc803c in XS_AUTOLOAD (my_perl=0x8f98008, cv=0x99da9d8)
> at src/util.cpp:1223
> classId = 5364
> methodId = <value optimized out>
> rcid = <value optimized out>
>
> It looks like a void pointer (ptr) is being passed to the sizePolicy,
> and I'm not sure if this is a Qt bug or a PerlQt bug. Either way it's
> due to improper checking of parameters -- ie maybe trying to
> dereference the null pointer.
>
> Thanks in advance for any help you can offer here.
>
> On an unrelated note, I've discovered while debugging code that
> "Carp::Always" is a very useful module. It makes calls to "die" dump a
> full backtrace, meaning the issues with ambiguous methods croak'ing
> from XS will dump a full backtrace. It's tremendously useful for
> debugging.
>
> Cheers,
>
> Jonathan
> _______________________________________________
> Kde-perl mailing list
> Kde-perl@...
> https://mail.kde.org/mailman/listinfo/kde-perl
>

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 were all described in the POD for PerlQt3. As I said, I don't know if
they still work in PerlQt4.
_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Suspicious QWidget Initialization Behaviour

2009-08-10T20:10:11Z

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();

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
(gdb) bt full
#0 QWidget::sizePolicy (this=0x0) at kernel/qwidget.cpp:8925
No locals.
#1 0xb7a6a938 in xcall_QWidget (xi=<value optimized out>, obj=0x0,
args=0x9bb7d08) at /home/jon/kdebindings/build/smoke/qt/x_20.cpp:4820
No locals.
#2 0xb7bd5153 in PerlQt::MethodCall::callMethod (this=0xbf9b1860)
at src/marshall_types.h:132
method = (Smoke::Method *) 0xb7b2feac
fn = (void (*)(short int, void *,
Smoke::StackItem *)) 0xb7a69c40 <xcall_QWidget(short, void*,
Smoke::StackItem*)>
ptr = (void *) 0x0
callreturn = {<PerlQt::MethodReturnValueBase> = {<Marshall> = {
_vptr.Marshall = 0xbf9b1668}, _smoke = 0x80abc27, _methodIndex = -31492,
_stack = 0x8f98548, _retval = 0xb7f32ff4}, <No data fields>}
#3 0xb7bd1f38 in PerlQt::MethodCallBase::next (this=0xbf9b1860)
at src/marshall_types.cpp:387
oldcur = -1
#4 0xb7bc803c in XS_AUTOLOAD (my_perl=0x8f98008, cv=0x99da9d8)
at src/util.cpp:1223
classId = 5364
methodId = <value optimized out>
rcid = <value optimized out>

It looks like a void pointer (ptr) is being passed to the sizePolicy,
and I'm not sure if this is a Qt bug or a PerlQt bug. Either way it's
due to improper checking of parameters -- ie maybe trying to
dereference the null pointer.

Thanks in advance for any help you can offer here.

On an unrelated note, I've discovered while debugging code that
"Carp::Always" is a very useful module. It makes calls to "die" dump a
full backtrace, meaning the issues with ambiguous methods croak'ing
from XS will dump a full backtrace. It's tremendously useful for
debugging.

Cheers,

Jonathan
_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Test Failures

2009-07-06T21:16:01Z

Hey Chris,

I'm not sure if you're back from vacation yet, but hopefully you come
across this soon :-)

I got Smoke and all that jazz installed on my Debian system. I had to
install it from source, which I'm not too happy about, grumble
grumble. The Debian package should be available by end of July though.

Anyway. I can compile perlqt4 just fine, but the tests are failing and
there is no indication of reasons why. Here is the output:

jon@wraith:~/perlqt4/branches/jawnsy$ perl Build
Copying lib/Qt/slots.pm -> blib/lib/Qt/slots.pm
Copying lib/Qt/signals.pm -> blib/lib/Qt/signals.pm
Copying lib/Qt/isa.pm -> blib/lib/Qt/isa.pm
Copying lib/Qt/classinfo.pm -> blib/lib/Qt/classinfo.pm
Copying lib/Qt/debug.pm -> blib/lib/Qt/debug.pm
Copying lib/Qt.pm -> blib/lib/Qt.pm
Copying src/Qt.xs -> lib/Qt.xs
lib/Qt.xs -> lib/Qt.c
cc -Isrc -I/usr/lib/perl/5.10/CORE -DXS_VERSION="0.01"
-DVERSION="0.01" -fPIC -std=gnu++98 -Wall -xc++ -I. -DQT_SHARED
-I/usr/include/qt4 -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore
-c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g
-o lib/Qt.o lib/Qt.c
lib/Qt.c: In function ‘void XS_Qt___internal_classIsa(PerlInterpreter*, CV*)’:
lib/Qt.c:42: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void XS_Qt___internal_findMethod(PerlInterpreter*, CV*)’:
lib/Qt.c:67: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void
XS_Qt___internal_getClassList(PerlInterpreter*, CV*)’:
lib/Qt.c:118: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void
XS_Qt___internal_getEnumList(PerlInterpreter*, CV*)’:
lib/Qt.c:145: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void XS_Qt___internal_getIsa(PerlInterpreter*, CV*)’:
lib/Qt.c:174: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void
XS_Qt___internal_getTypeNameOfArg(PerlInterpreter*, CV*)’:
lib/Qt.c:202: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void XS_Qt___internal_getSVt(PerlInterpreter*, CV*)’:
lib/Qt.c:229: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void XS_Qt___internal_idClass(PerlInterpreter*, CV*)’:
lib/Qt.c:253: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void
XS_Qt___internal_installautoload(PerlInterpreter*, CV*)’:
lib/Qt.c:277: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void
XS_Qt___internal_installqt_metacall(PerlInterpreter*, CV*)’:
lib/Qt.c:302: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void
XS_Qt___internal_installsignal(PerlInterpreter*, CV*)’:
lib/Qt.c:328: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void
XS_Qt___internal_installsuper(PerlInterpreter*, CV*)’:
lib/Qt.c:350: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void
XS_Qt___internal_installthis(PerlInterpreter*, CV*)’:
lib/Qt.c:378: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void
XS_Qt___internal_make_metaObject(PerlInterpreter*, CV*)’:
lib/Qt.c:406: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void XS_Qt___internal_isObject(PerlInterpreter*, CV*)’:
lib/Qt.c:499: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void XS_Qt___internal_setDebug(PerlInterpreter*, CV*)’:
lib/Qt.c:523: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void XS_Qt___internal_setQApp(PerlInterpreter*, CV*)’:
lib/Qt.c:544: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void XS_Qt___internal_setThis(PerlInterpreter*, CV*)’:
lib/Qt.c:566: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void XS_Qt___internal_sv_to_ptr(PerlInterpreter*, CV*)’:
lib/Qt.c:587: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void XS_Qt_this(PerlInterpreter*, CV*)’:
lib/Qt.c:610: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void XS_Qt_qApp(PerlInterpreter*, CV*)’:
lib/Qt.c:633: warning: unused variable ‘Perl___notused’
lib/Qt.c: In function ‘void boot_Qt(PerlInterpreter*, CV*)’:
lib/Qt.c:665: warning: deprecated conversion from string constant to ‘char*’
lib/Qt.c:661: warning: unused variable ‘Perl___notused’
ExtUtils::Mkbootstrap::Mkbootstrap('blib/arch/auto/Qt/Qt.bs')
cc -shared -O2 -g -L/usr/local/lib -o blib/arch/auto/Qt/Qt.so lib/Qt.o
src/binding.o src/handlers.o src/util.o src/marshall_types.o -lsmokeqt
-lQtGui -lQtCore
Manifying blib/lib/Qt.pm -> blib/libdoc/Qt.3pm
jon@wraith:~/perlqt4/branches/jawnsy$ ls
blib _build Changes examples Makefile.PL src tools
Build Build.PL CMakeLists.txt lib MANIFEST t
jon@wraith:~/perlqt4/branches/jawnsy$ perl Build test
t/a_loading............ok
t/c_qapp...............dubious
Test returned status 0 (wstat 11, 0xb)
DIED. FAILED test 3
Failed 1/3 tests, 66.67% okay
t/d_sigslot............dubious
Test returned status 0 (wstat 11, 0xb)
DIED. FAILED tests 2-4
Failed 3/4 tests, 25.00% okay
t/e_sigslot_inherit....dubious
Test returned status 0 (wstat 11, 0xb)
DIED. FAILED tests 1-7
Failed 7/7 tests, 0.00% okay
t/f_handlers...........dubious
Test returned status 0 (wstat 11, 0xb)
DIED. FAILED tests 1-16
Failed 16/16 tests, 0.00% okay
Failed Test Stat Wstat Total Fail List of Failed
-------------------------------------------------------------------------------
t/c_qapp.t 0 11 3 2 3
t/d_sigslot.t 0 11 4 6 2-4
t/e_sigslot_inherit.t 0 11 7 14 1-7
t/f_handlers.t 0 11 16 32 1-16
Failed 4/5 test scripts. 27/31 subtests failed.
Files=5, Tests=31, 3 wallclock secs ( 0.58 cusr + 0.58 csys = 1.16 CPU)
Failed 4/5 test programs. 27/31 subtests failed.
jon@wraith:~/perlqt4/branches/jawnsy$
_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Re: [Kde-bindings] FTBFS; perlqt4 and Smoke Missing Method Errors

2009-06-19T18:47:43Z

Hmm.

Chris, thanks for the response.

The problem is the Debian packages are borked (not sure why I didn't
see these issues on Kubuntu). Not your fault, I know.

libsmokeqt4-dev contains the headers that I need to compile. BUT they
are headers for libsmokeqt4-1 which is installed as well. It says it
is version 1.4.10, not sure if that's the KDE version. It does say qt4
though......

Unfortunately libsmokeqt-dev (different package) refers to KDE 3.5.10

Hmm. Very interesting indeed.

On Fri, Jun 19, 2009 at 8:46 PM, Chris Burel<chrisburel@...> wrote:

> Hey Jonathan,
> I think the smoke.h that it's picking up is old. That's what the
> 'ModuleIndex’ is not a member of ‘Smoke’ business is about. There's a
> release of QtRuby that still uses the old smoke.h, so maybe that's
> where it's coming from. Make sure that it's getting the smoke.h from
> the kdebindings release from kde version 4.2.0 or greater. (I'm not
> exactly sure where the ModuleIndex was introduced, but I know I built
> successfully against that version.)
>
> On Sat, Jun 20, 2009 at 9:24 AM, Jonathan Yu<jonathan.i.yu@...> wrote:
>> Hi all.
>>
>> I'm trying to build my branch of perlqt4, which has built for me
>> successfully in the past, but on a Kubuntu machine. I'm now on a
>> Debian machine. Did something in Smoke change? Am I using the wrong
>> version of libsmoke (there are two available in Debian, I'm using
>> libsmokeqt4-2)
>>
>> Any wisdom you can offer with respect to why these errors are
>> appearing would be great.
>>
>> It also seems that the Build process might be trying to build using a
>> C compiler instead of C++, but judging by the output I don't think
>> that's the case.
>>
>> --
>>
>> wraith:/home/jon/perlqt4/branches/jawnsy# perl Build
>> cc -Isrc -I/usr/lib/perl/5.10/CORE -fPIC -std=gnu++98 -Wall -xc++ -I.
>> -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtGui
>> -I/usr/include/qt4/QtCore -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN
>> -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
>> -D_FILE_OFFSET_BITS=64 -O2 -g -o src/handlers.o src/handlers.cpp
>> In file included from src/handlers.cpp:71:
>> src/marshall_macros.h: In function ‘void marshall_ItemList(Marshall*)’:
>> src/marshall_macros.h:69: error: request for member ‘index’ in
>> ‘o->.smoke->.Smoke::idClass(ItemSTR)’, which is of non-class type
>> ‘short int’
>> src/marshall_macros.h: In function ‘void marshall_ValueListItem(Marshall*)’:
>> src/marshall_macros.h:166: error: request for member ‘index’ in
>> ‘o->.smoke->.Smoke::idClass("QVariant")’, which is of non-class type
>> ‘short int’
>> src/marshall_macros.h:188: error: request for member ‘index’ in
>> ‘o->.smoke->.Smoke::idClass(ItemSTR)’, which is of non-class type
>> ‘short int’
>> src/handlers.cpp: In function ‘void invoke_dtor(smokeperl_object*)’:
>> src/handlers.cpp:96: error: request for member ‘index’ in
>> ‘o->smokeperl_object::smoke->Smoke::findMethod(className, ((const
>> char*)methodName))’, which is of non-class type ‘short int’
>> src/handlers.cpp: In function ‘void* construct_copy(smokeperl_object*)’:
>> src/handlers.cpp:124: error: ‘ModuleIndex’ is not a member of ‘Smoke’
>> src/handlers.cpp:124: error: expected `;' before ‘ccId’
>> src/handlers.cpp:130: error: ‘ModuleIndex’ is not a member of ‘Smoke’
>> src/handlers.cpp:130: error: expected `;' before ‘classIdx’
>> src/handlers.cpp:131: error: ‘classIdx’ was not declared in this scope
>> src/handlers.cpp:131: error: ‘ccId’ was not declared in this scope
>> src/handlers.cpp: In function ‘void marshall_basetype(Marshall*)’:
>> src/handlers.cpp:331: error: request for member ‘index’ in
>> ‘o->smokeperl_object::smoke->Smoke::idClass(c->Smoke::Class::className)’,
>> which is of non-class type ‘short int’
>> src/handlers.cpp: In function ‘void marshall_QMapQStringQVariant(Marshall*)’:
>> src/handlers.cpp:1296: error: ‘class Smoke’ has no member named ‘findClass’
>> src/handlers.cpp: In function ‘void marshall_QMapIntQVariant(Marshall*)’:
>> src/handlers.cpp:1380: error: ‘class Smoke’ has no member named ‘findClass’
>> error building src/handlers.o from 'src/handlers.cpp' at
>> /usr/share/perl/5.10/ExtUtils/CBuilder/Base.pm line 109.
>> _______________________________________________
>> Kde-bindings mailing list
>> Kde-bindings@...
>> https://mail.kde.org/mailman/listinfo/kde-bindings
>>
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings@...
> https://mail.kde.org/mailman/listinfo/kde-bindings
>

_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

FTBFS; perlqt4 and Smoke Missing Method Errors

2009-06-19T17:24:47Z

Hi all.

I'm trying to build my branch of perlqt4, which has built for me
successfully in the past, but on a Kubuntu machine. I'm now on a
Debian machine. Did something in Smoke change? Am I using the wrong
version of libsmoke (there are two available in Debian, I'm using
libsmokeqt4-2)

Any wisdom you can offer with respect to why these errors are
appearing would be great.

It also seems that the Build process might be trying to build using a
C compiler instead of C++, but judging by the output I don't think
that's the case.

--

wraith:/home/jon/perlqt4/branches/jawnsy# perl Build
cc -Isrc -I/usr/lib/perl/5.10/CORE -fPIC -std=gnu++98 -Wall -xc++ -I.
-DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtGui
-I/usr/include/qt4/QtCore -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -O2 -g -o src/handlers.o src/handlers.cpp
In file included from src/handlers.cpp:71:
src/marshall_macros.h: In function ‘void marshall_ItemList(Marshall*)’:
src/marshall_macros.h:69: error: request for member ‘index’ in
‘o->.smoke->.Smoke::idClass(ItemSTR)’, which is of non-class type
‘short int’
src/marshall_macros.h: In function ‘void marshall_ValueListItem(Marshall*)’:
src/marshall_macros.h:166: error: request for member ‘index’ in
‘o->.smoke->.Smoke::idClass("QVariant")’, which is of non-class type
‘short int’
src/marshall_macros.h:188: error: request for member ‘index’ in
‘o->.smoke->.Smoke::idClass(ItemSTR)’, which is of non-class type
‘short int’
src/handlers.cpp: In function ‘void invoke_dtor(smokeperl_object*)’:
src/handlers.cpp:96: error: request for member ‘index’ in
‘o->smokeperl_object::smoke->Smoke::findMethod(className, ((const
char*)methodName))’, which is of non-class type ‘short int’
src/handlers.cpp: In function ‘void* construct_copy(smokeperl_object*)’:
src/handlers.cpp:124: error: ‘ModuleIndex’ is not a member of ‘Smoke’
src/handlers.cpp:124: error: expected `;' before ‘ccId’
src/handlers.cpp:130: error: ‘ModuleIndex’ is not a member of ‘Smoke’
src/handlers.cpp:130: error: expected `;' before ‘classIdx’
src/handlers.cpp:131: error: ‘classIdx’ was not declared in this scope
src/handlers.cpp:131: error: ‘ccId’ was not declared in this scope
src/handlers.cpp: In function ‘void marshall_basetype(Marshall*)’:
src/handlers.cpp:331: error: request for member ‘index’ in
‘o->smokeperl_object::smoke->Smoke::idClass(c->Smoke::Class::className)’,
which is of non-class type ‘short int’
src/handlers.cpp: In function ‘void marshall_QMapQStringQVariant(Marshall*)’:
src/handlers.cpp:1296: error: ‘class Smoke’ has no member named ‘findClass’
src/handlers.cpp: In function ‘void marshall_QMapIntQVariant(Marshall*)’:
src/handlers.cpp:1380: error: ‘class Smoke’ has no member named ‘findClass’
error building src/handlers.o from 'src/handlers.cpp' at
/usr/share/perl/5.10/ExtUtils/CBuilder/Base.pm line 109.
_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Re: Converting Qt4 QString to ordinary Perl string

2009-06-18T09:27:30Z

On Thursday 18 June 2009 04:34:05 pm Gary Greene wrote:

> On Wednesday 17 June 2009 05:22:20 am Richard Dale wrote:
> > On Tuesday 16 June 2009 09:46:27 pm Chris Burel wrote:
> > > As I recall from when I looked at that version of the binding from a
> > > year ago, you have to go through a roundabout method to get the data
> > > out of the QString object.
> > >
> > > my $i = 0;
> > > my $perlStr = '';
> > > while( $i < $string->count() ) {
> > > $perlStr .= chr( $string->at($i)->cell() );
> > > $i++
> > > }
> > > print $perlStr;
> > > Hi there
> > >
> > > Very difficult. This was one of the reasons the smoke-based PerlQt4
> > > project was started. The link has already been posted.
> >
> > One related point is that in PerlQt Qt3, a QByteArray was mapped onto a
> > Perl string. But I found that was more trouble than it's worth in QtRuby,
> > and so Qt::ByteArray is now a class, and not a string anymore.
> >
> > -- Richard
> > _______________________________________________
> > Kde-perl mailing list
> > Kde-perl@...
> > https://mail.kde.org/mailman/listinfo/kde-perl
>
> As long as there is a way to convert TO a string for QByteArrays that
> shouldn't be too much of a problem. (Yes, I've run into code that needs
> that.)

Yes that's right - I added a 'to_s()' method in Ruby to do that by calling
constData() on the QByteArray, and so you'll need to add a custom equivalent
for Perl.

-- Richard
_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Re: Converting Qt4 QString to ordinary Perl string

2009-06-18T08:34:05Z

On Wednesday 17 June 2009 05:22:20 am Richard Dale wrote:

> On Tuesday 16 June 2009 09:46:27 pm Chris Burel wrote:
> > As I recall from when I looked at that version of the binding from a
> > year ago, you have to go through a roundabout method to get the data
> > out of the QString object.
> >
> > my $i = 0;
> > my $perlStr = '';
> > while( $i < $string->count() ) {
> > $perlStr .= chr( $string->at($i)->cell() );
> > $i++
> > }
> > print $perlStr;
> > Hi there
> >
> > Very difficult. This was one of the reasons the smoke-based PerlQt4
> > project was started. The link has already been posted.
>
> One related point is that in PerlQt Qt3, a QByteArray was mapped onto a
> Perl string. But I found that was more trouble than it's worth in QtRuby,
> and so Qt::ByteArray is now a class, and not a string anymore.
>
> -- Richard
> _______________________________________________
> Kde-perl mailing list
> Kde-perl@...
> https://mail.kde.org/mailman/listinfo/kde-perl

As long as there is a way to convert TO a string for QByteArrays that
shouldn't be too much of a problem. (Yes, I've run into code that needs
that.)

--
Gary L. Greene, Jr.
Sent from: peorth.tolharadys.net
08:33:06 up 45 days, 59 min, 3 users, load average: 0.39, 0.58, 0.61
==========================================================================
Developer and Project Lead for the AltimatOS open source project
Volunteer Developer for the KDE open source project
See http://www.altimatos.com/ and http://www.kde.org/ for more information
==========================================================================

Please avoid sending me Word or PowerPoint attachments.

_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

signature.asc (196 bytes) Download Attachment

Re: Converting Qt4 QString to ordinary Perl string

2009-06-17T05:22:20Z

On Tuesday 16 June 2009 09:46:27 pm Chris Burel wrote:

> As I recall from when I looked at that version of the binding from a
> year ago, you have to go through a roundabout method to get the data
> out of the QString object.
>
> my $i = 0;
> my $perlStr = '';
> while( $i < $string->count() ) {
> $perlStr .= chr( $string->at($i)->cell() );
> $i++
> }
> print $perlStr;
> Hi there
>
> Very difficult. This was one of the reasons the smoke-based PerlQt4
> project was started. The link has already been posted.

One related point is that in PerlQt Qt3, a QByteArray was mapped onto a Perl
string. But I found that was more trouble than it's worth in QtRuby, and so
Qt::ByteArray is now a class, and not a string anymore.

-- Richard
_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Re: Converting Qt4 QString to ordinary Perl string

2009-06-16T13:46:27Z

As I recall from when I looked at that version of the binding from a
year ago, you have to go through a roundabout method to get the data
out of the QString object.

my $i = 0;
my $perlStr = '';
while( $i < $string->count() ) {
$perlStr .= chr( $string->at($i)->cell() );
$i++
}
print $perlStr;
Hi there

Very difficult. This was one of the reasons the smoke-based PerlQt4
project was started. The link has already been posted.

On Sun, Jun 14, 2009 at 10:51 AM, Eric
Wilhelm<ewilhelm@...> wrote:

> # from Adam Bar
> # on Friday 12 June 2009 15:37:
>
>>My question is maybe stupid, but I am looking for few hours for the
>>solution - how to get string value from variable blessed QString?
>>my $str = 'string';
>>my $obj = QString($str);
>># how to get 'string' from $obj ?
>>
>>Methods like latin1(), ascii() are not defined in my perl binding.
>>
>>I am using Perl Qt 4.004, Perl 5.8.8.
>
> Hi Adam,
>
> Where did you get this Qt.pm? I think you must be running the non-smoke
> QtCore+QtGUI distros.
>
> http://search.cpan.org/~vadiml/QtCore-4.004/
>
> I haven't looked at that much except to determine that the API was
> fabricated from generated XS code and seems to require that every
> string be constructed using a QString() function -- which is not very
> perlish. The developer also does not seem to respond to any of my
> mail.
>
> On the other hand:
>
> http://code.google.com/p/perlqt4/
>
> This intends to be a successor to the old PerlQt (3) and will work much
> like it. Plus, the maintainers of this code *are* on this list.
> However, it isn't on the CPAN yet.
>
> --Eric
> --
> If the above message is encrypted and you have lost your pgp key, please
> send a self-addressed, stamped lead box to the address below.
> ---------------------------------------------------
> http://scratchcomputing.com
> ---------------------------------------------------
> _______________________________________________
> Kde-perl mailing list
> Kde-perl@...
> https://mail.kde.org/mailman/listinfo/kde-perl
>

_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Re: Converting Qt4 QString to ordinary Perl string

2009-06-13T18:51:01Z

# from Adam Bar
# on Friday 12 June 2009 15:37:

>My question is maybe stupid, but I am looking for few hours for the
>solution - how to get string value from variable blessed QString?
>my $str = 'string';
>my $obj = QString($str);
># how to get 'string' from $obj ?
>
>Methods like latin1(), ascii() are not defined in my perl binding.
>
>I am using Perl Qt 4.004, Perl 5.8.8.

Hi Adam,

Where did you get this Qt.pm? I think you must be running the non-smoke
QtCore+QtGUI distros.

http://search.cpan.org/~vadiml/QtCore-4.004/

I haven't looked at that much except to determine that the API was
fabricated from generated XS code and seems to require that every
string be constructed using a QString() function -- which is not very
perlish. The developer also does not seem to respond to any of my
mail.

On the other hand:

http://code.google.com/p/perlqt4/

This intends to be a successor to the old PerlQt (3) and will work much
like it. Plus, the maintainers of this code *are* on this list.
However, it isn't on the CPAN yet.

--Eric
--
If the above message is encrypted and you have lost your pgp key, please
send a self-addressed, stamped lead box to the address below.
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Re: Converting Qt4 QString to ordinary Perl string

2009-06-13T11:43:38Z

On Saturday 13 June 2009 05:16:56 am Adam Bar wrote:

> 2009/6/13 Gary Greene <greeneg@...>
>
> > Probably you'll have to marshal using some custom code in those bindings
> > the data from Qt using std::string QString::toStdString into Perl's SVpv.
> > See http://doc.trolltech.com/4.5/qstring.html#toStdString for info on
> > that method.
>
> There is no toStdString() in binding too. You say that I need to work
> with binding code? It's not possible in ordinary Perl code? It is too
> much for a newbie like me, thank you :)
>
> A.
> _______________________________________________
> Kde-perl mailing list
> Kde-perl@...
> https://mail.kde.org/mailman/listinfo/kde-perl

If they are missing that function in their code, then, those bindings are old
and don't support current Qt. Which version of Qt are these bindings built
against?

--
Gary L. Greene, Jr.
Sent from: peorth.tolharadys.net
11:41:53 up 40 days, 4:07, 3 users, load average: 0.68, 0.73, 0.64
==========================================================================
Developer and Project Lead for the AltimatOS open source project
Volunteer Developer for the KDE open source project
See http://www.altimatos.com/ and http://www.kde.org/ for more information
==========================================================================

Please avoid sending me Word or PowerPoint attachments.

_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

signature.asc (196 bytes) Download Attachment

Re: Converting Qt4 QString to ordinary Perl string

2009-06-13T05:16:56Z

2009/6/13 Gary Greene <greeneg@...>
>
> Probably you'll have to marshal using some custom code in those bindings the
> data from Qt using std::string QString::toStdString into Perl's SVpv. See
> http://doc.trolltech.com/4.5/qstring.html#toStdString for info on that
> method.

There is no toStdString() in binding too. You say that I need to work
with binding code? It's not possible in ordinary Perl code? It is too
much for a newbie like me, thank you :)

A.
_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Re: Converting Qt4 QString to ordinary Perl string

2009-06-13T00:14:43Z

On Friday 12 June 2009 03:37:53 pm Adam Bar wrote:

> Hello everyone,
>
> My question is maybe stupid, but I am looking for few hours for the
> solution - how to get string value from variable blessed QString?
> my $str = 'string';
> my $obj = QString($str);
> # how to get 'string' from $obj ?
>
> Methods like latin1(), ascii() are not defined in my perl binding.
>
> I am using Perl Qt 4.004, Perl 5.8.8.
>
> Thanks in advance!
> Adam
> _______________________________________________
> Kde-perl mailing list
> Kde-perl@...
> https://mail.kde.org/mailman/listinfo/kde-perl

Probably you'll have to marshal using some custom code in those bindings the
data from Qt using std::string QString::toStdString into Perl's SVpv. See
http://doc.trolltech.com/4.5/qstring.html#toStdString for info on that
method.

--
Gary L. Greene, Jr.
Sent from: peorth.tolharadys.net
00:02:57 up 39 days, 16:29, 3 users, load average: 0.65, 0.66, 0.59
==========================================================================
Developer and Project Lead for the AltimatOS open source project
Volunteer Developer for the KDE open source project
See http://www.altimatos.com/ and http://www.kde.org/ for more information
==========================================================================

Please avoid sending me Word or PowerPoint attachments.

_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

signature.asc (196 bytes) Download Attachment

Converting Qt4 QString to ordinary Perl string

2009-06-12T15:37:53Z

Hello everyone,

My question is maybe stupid, but I am looking for few hours for the
solution - how to get string value from variable blessed QString?
my $str = 'string';
my $obj = QString($str);
# how to get 'string' from $obj ?

Methods like latin1(), ascii() are not defined in my perl binding.

I am using Perl Qt 4.004, Perl 5.8.8.

Thanks in advance!
Adam
_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Re: [Kde-bindings] Adding more explicit ambiguous method lookup resolution for PerlQt

2009-06-10T06:05:29Z

I think another thing we can do is implement objects in Perl, like:
QInt, QUint, QBool.. which we would pass to the variant method (on the
Perl side) and then have it automatically pick the right overloaded
version of the method.

Another possibility is to pass a hash reference, like:

Qt::Variant({
1,
type => bool
});

or something.

I'm not sure how this might be done on the Ruby side, however.

On Wed, Jun 10, 2009 at 2:09 AM, Gary L. Greene,
Jr.<greeneg@...> wrote:

> On 6/9/09 10:28 PM, "Chris Burel" <chrisburel@...> wrote:
>
>> Hey guys,
>> Sorry for double posting, but I wanted to get Ruby's opinion on this too.
>>
>> One thing in PerlQt that can be very frustrating is when the bindings
>> cannot determine which method you intend to call based on the
>> arguments. A common example of this happens with the QVariant class,
>> because it's essentially a union class that has constructors for a
>> bunch of different data types. Consider:
>> my $foo = Qt::Variant(1)
>> results in
>>
>> --- Ambiguous method QVariant::QVariant called
>> Candidates are:
>> QVariant::QVariant( uint )
>> QVariant::QVariant( int )
>> QVariant::QVariant( bool )
>> Choosing first one...
>>
>> It's frustrating because the bindings clearly know that the other
>> method exists, and sometimes you really do want to call the other
>> method. But how should you specify which method you really want?
>>
>> I was thinking that if we already have the method's signature, and it
>> is unique, why not let the coder specify the exact signature they want
>> to call? Something along the lines of
>> Qt::setSignature( 'QVariant::QVariant( bool )' );
>> my $foo = Qt::Variant(1);
>> That way the coder can force the bindings to call the correct method.
>>
>> It can really help for things like the QSignalMapper, that has these 2
>> functions:
>> void setMapping ( QObject * sender, QWidget * widget )
>> void setMapping ( QObject * sender, QObject * object )
>> Because of the ambiguity, the coder doesn't know if she/he should
>> connect to the 'mapped( QWidget * widget )' signal or the 'mapped(
>> QObject * object )' signal.
>>
>> Thoughts?
>>
>> -Chris
>> _______________________________________________
>> Kde-bindings mailing list
>> Kde-bindings@...
>> https://mail.kde.org/mailman/listinfo/kde-bindings
>
> I agree with this, since it's bit me more than a few times, and would
> (surprise, surprise) make working on KDE bindings for Perl that much easier
> since there are times in the code (especially in the XMLGUI stuff) where a
> similar aspect occurs for the various template segments. Richard, you're
> thoughts?
>
>
>

_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Adding more explicit ambiguous method lookup resolution for PerlQt

2009-06-09T22:28:33Z

Hey guys,
Sorry for double posting, but I wanted to get Ruby's opinion on this too.

One thing in PerlQt that can be very frustrating is when the bindings
cannot determine which method you intend to call based on the
arguments. A common example of this happens with the QVariant class,
because it's essentially a union class that has constructors for a
bunch of different data types. Consider:
my $foo = Qt::Variant(1)
results in

--- Ambiguous method QVariant::QVariant called
Candidates are:
QVariant::QVariant( uint )
QVariant::QVariant( int )
QVariant::QVariant( bool )
Choosing first one...

It's frustrating because the bindings clearly know that the other
method exists, and sometimes you really do want to call the other
method. But how should you specify which method you really want?

I was thinking that if we already have the method's signature, and it
is unique, why not let the coder specify the exact signature they want
to call? Something along the lines of
Qt::setSignature( 'QVariant::QVariant( bool )' );
my $foo = Qt::Variant(1);
That way the coder can force the bindings to call the correct method.

It can really help for things like the QSignalMapper, that has these 2
functions:
void setMapping ( QObject * sender, QWidget * widget )
void setMapping ( QObject * sender, QObject * object )
Because of the ambiguity, the coder doesn't know if she/he should
connect to the 'mapped( QWidget * widget )' signal or the 'mapped(
QObject * object )' signal.

Thoughts?

-Chris
_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Re: Qt Compile Flags (Was: Compiling Without Installing)

2009-06-03T18:53:33Z

Oh- Chris, we (ewilhelm and I) made a channel on irc.perl.org - #qt

If you can join, it's probably more useful for quick questions than
the mailing list.

Right now I'm getting an error building from source - see
http://sial.org/pbot/37016

any ideas?

On Wed, Jun 3, 2009 at 9:49 PM, Jonathan Yu <jonathan.i.yu@...> wrote:

> Impressive. Well, in that case, what is outstanding that you'd like me
> to hack on? Is there a particular area you want me to focus on?
>
> On Wed, Jun 3, 2009 at 9:46 PM, Chris Burel <chrisburel@...> wrote:
>> Was it this one?
>> http://code.google.com/p/perlqt4/issues/detail?id=3&can=1
>>
>> That ended up being related to the perl compile options, related to
>> how it handles allocating memory for environment variables.
>>
>> On Wed, Jun 3, 2009 at 6:31 PM, Jonathan Yu <jonathan.i.yu@...> wrote:
>>> Well, it was the issue that was reported in code.google.org; that I
>>> was initially brought into this project to get fixed, in the first
>>> place...
>>>
>>> On Wed, Jun 3, 2009 at 9:28 PM, Chris Burel <chrisburel@...> wrote:
>>>>> Right now the big push is
>>>>> fixing that nasty issue with the segfaults, so I'll fix my module,
>>>>> finish compiling and hack on that. :-)
>>>>
>>>> What segfaults are you experiencing?
>>>> _______________________________________________
>>>> Kde-perl mailing list
>>>> Kde-perl@...
>>>> https://mail.kde.org/mailman/listinfo/kde-perl
>>>>
>>> _______________________________________________
>>> Kde-perl mailing list
>>> Kde-perl@...
>>> https://mail.kde.org/mailman/listinfo/kde-perl
>>>
>> _______________________________________________
>> Kde-perl mailing list
>> Kde-perl@...
>> https://mail.kde.org/mailman/listinfo/kde-perl
>>
>

_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Re: Qt Compile Flags (Was: Compiling Without Installing)

2009-06-03T18:49:43Z

Impressive. Well, in that case, what is outstanding that you'd like me
to hack on? Is there a particular area you want me to focus on?

On Wed, Jun 3, 2009 at 9:46 PM, Chris Burel <chrisburel@...> wrote:

> Was it this one?
> http://code.google.com/p/perlqt4/issues/detail?id=3&can=1
>
> That ended up being related to the perl compile options, related to
> how it handles allocating memory for environment variables.
>
> On Wed, Jun 3, 2009 at 6:31 PM, Jonathan Yu <jonathan.i.yu@...> wrote:
>> Well, it was the issue that was reported in code.google.org; that I
>> was initially brought into this project to get fixed, in the first
>> place...
>>
>> On Wed, Jun 3, 2009 at 9:28 PM, Chris Burel <chrisburel@...> wrote:
>>>> Right now the big push is
>>>> fixing that nasty issue with the segfaults, so I'll fix my module,
>>>> finish compiling and hack on that. :-)
>>>
>>> What segfaults are you experiencing?
>>> _______________________________________________
>>> Kde-perl mailing list
>>> Kde-perl@...
>>> https://mail.kde.org/mailman/listinfo/kde-perl
>>>
>> _______________________________________________
>> Kde-perl mailing list
>> Kde-perl@...
>> https://mail.kde.org/mailman/listinfo/kde-perl
>>
> _______________________________________________
> Kde-perl mailing list
> Kde-perl@...
> https://mail.kde.org/mailman/listinfo/kde-perl
>

_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Re: Qt Compile Flags (Was: Compiling Without Installing)

2009-06-03T18:46:17Z

Was it this one?
http://code.google.com/p/perlqt4/issues/detail?id=3&can=1

That ended up being related to the perl compile options, related to
how it handles allocating memory for environment variables.

On Wed, Jun 3, 2009 at 6:31 PM, Jonathan Yu <jonathan.i.yu@...> wrote:

> Well, it was the issue that was reported in code.google.org; that I
> was initially brought into this project to get fixed, in the first
> place...
>
> On Wed, Jun 3, 2009 at 9:28 PM, Chris Burel <chrisburel@...> wrote:
>>> Right now the big push is
>>> fixing that nasty issue with the segfaults, so I'll fix my module,
>>> finish compiling and hack on that. :-)
>>
>> What segfaults are you experiencing?
>> _______________________________________________
>> Kde-perl mailing list
>> Kde-perl@...
>> https://mail.kde.org/mailman/listinfo/kde-perl
>>
> _______________________________________________
> Kde-perl mailing list
> Kde-perl@...
> https://mail.kde.org/mailman/listinfo/kde-perl
>

_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Re: Qt Compile Flags (Was: Compiling Without Installing)

2009-06-03T18:31:16Z

Well, it was the issue that was reported in code.google.org; that I
was initially brought into this project to get fixed, in the first
place...

On Wed, Jun 3, 2009 at 9:28 PM, Chris Burel <chrisburel@...> wrote:

>> Right now the big push is
>> fixing that nasty issue with the segfaults, so I'll fix my module,
>> finish compiling and hack on that. :-)
>
> What segfaults are you experiencing?
> _______________________________________________
> Kde-perl mailing list
> Kde-perl@...
> https://mail.kde.org/mailman/listinfo/kde-perl
>

_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Re: Qt Compile Flags (Was: Compiling Without Installing)

2009-06-03T18:28:43Z

> Right now the big push is
> fixing that nasty issue with the segfaults, so I'll fix my module,
> finish compiling and hack on that. :-)

What segfaults are you experiencing?
_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl

Re: Qt Compile Flags (Was: Compiling Without Installing)

2009-06-03T17:14:05Z

Chris:

I don't think normal installs are a problem, per se, I just have no
experience setting up that sort of thing.

It's easier to find things when they're system-installed -- you can
check in the usual library paths. However, when they're installed in
the user directory, they can really be anywhere. So the App::Info
instance would need to be able to account for that. Just adds a bit of
extra complexity, and I'm not sure how the other modules do that sort
of thing.

Anyway, I think all of this is nice to have discussed up front, but it
should be put on the back burner for now. Right now the big push is
fixing that nasty issue with the segfaults, so I'll fix my module,
finish compiling and hack on that. :-)

Cheers,

Jonathan

On Wed, Jun 3, 2009 at 4:54 PM, Chris Burel <chrisburel@...> wrote:

> I used the Makefile.PL because that's what
> h2xs -A -n Qt
> gave me. It compiled what I needed, so all was good. If you guys
> think we should use Module::Build, and want to convert over, be my
> guest.
> It also sounds like a good idea to package smokeqt as an
> Alien::SmokeQt package. Remember that there are Smoke objects for
> different parts of Qt, KDE, Phonon, etc, that are all separate. For
> instance, qtuitools, qt, and qtscript all have separate smoke objects.
> So we'd want the module called Alien::SmokeQt, so that in the future
> we can have Alien::SmokeQtUiTools, Alien::SmokeQtScript, etc. I'd
> vote for Alien::SmokeQt over Alien::QtSmoke because the library that
> gets built is called libsmokeqt, not libqtsmoke.
>
> I don't see why you wouldn't be able to tell the Alien::SmokeQt
> package to install to your home directory, and then have PerlQt link
> to it from there. Why would normal user account installs be a
> problem?
>
> On Wed, Jun 3, 2009 at 1:36 PM, Jonathan Yu <jonathan.i.yu@...> wrote:
>> Eric:
>>
>> Actually, an Alien:: package (or several) seems like a good idea.
>>
>> One thing I'm not sure about, though, is whether Alien:: packages
>> should be designed to work with normal user accounts (ie non-root CPAN
>> installs). I'm not even sure what package to use as a reference for
>> this -- I did look at Alien::Judy which is a simple enough package
>> that I can sort of grasp what is happening.
>>
>> Moreover, I'd want to reduce the build dependencies if possible,
>> especially in the case where there are modules already installed on
>> the system. I'd like it if users didn't have to download the Alien::
>> stuff if App::Info detects that it's already installed (App::Info
>> would be a build dependency, rather than a full out dependency).
>>
>> This is particularly useful for people that are on systems like, say,
>> Debian.. where the trick is to find out if there is a system-installed
>> version, or ask the user otherwise. Perhaps the Alien package could be
>> used as a convenience, more like:
>>
>> 1. Download App::Info for Smoke
>> 2. Check if libsmokeqt is installed
>> 3. If it is, then use it; otherwise:
>> 4. Prompt the user to install it, ask if it's okay, etc (maybe EUMM's
>> prompt subroutine can be used for this)
>> 5. Install Alien::Smoke etc via CPAN
>>
>> If the lib is already installed, then (as detected by App::Info), then
>> you wouldn't need to install the Alien version via CPAN. Thus
>> Alien::Smoke wouldn't be a direct dependency.
>>
>> Cheers,
>>
>> Jonathan
>>
>> On Wed, Jun 3, 2009 at 4:07 PM, Eric Wilhelm
>> <ewilhelm@...> wrote:
>>> # from Jonathan Yu
>>> # on Wednesday 03 June 2009 13:00:
>>>
>>>>I'll work over the next couple days with getting the Makefile.PL to
>>>>detect if smoke is installed and die otherwise (since this is
>>>>something CMake takes care of, right?). Then it can be uploaded to
>>>>CPAN as-is. I'm currently looking into extending App::Info to help us
>>>>find Qt stuff (see App::Info on CPAN).
>>>
>>> One idea here is to have an Alien::Smoke and/or Alien::Qt packages (ala
>>> Alien::wxWidgets) which allows you to break those dependencies into
>>> separate dists -- so you can automatically install everything with the
>>> cpan client, but you can also quickly upgrade the Qt4 dist for
>>> perl-only changes.
>>>
>>>>do you mind if I upgrade the build over to Build.PL?
>>>>...is much more capable of handling complex tasks than Makefile.PL
>>>
>>> I'll second that. (Disclaimer: I'm the Module::Build maintainer.)
>>>
>>> --Eric
>>> --
>>> The opinions expressed in this e-mail were randomly generated by
>>> the computer and do not necessarily reflect the views of its owner.
>>> --Management
>>> ---------------------------------------------------
>>> http://scratchcomputing.com
>>> ---------------------------------------------------
>>> _______________________________________________
>>> Kde-perl mailing list
>>> Kde-perl@...
>>> https://mail.kde.org/mailman/listinfo/kde-perl
>>>
>> _______________________________________________
>> Kde-perl mailing list
>> Kde-perl@...
>> https://mail.kde.org/mailman/listinfo/kde-perl
>>
> _______________________________________________
> Kde-perl mailing list
> Kde-perl@...
> https://mail.kde.org/mailman/listinfo/kde-perl
>

_______________________________________________
Kde-perl mailing list
Kde-perl@...
https://mail.kde.org/mailman/listinfo/kde-perl