[Kde-bindings] PerlQt constructor syntax

Jonathan Yu frequency at cpan.org
Mon Jun 1 18:28:31 UTC 2009


All:

(This relates to the Qt4 Perl bindings, managed by Chris Burel et. al.
If this is interesting to you, please read on.)

Given that a lot of qt4-related packages have names like:

libsmokeqt4-1 - Smoke library for Qt4

Rather than simply

libsmokeqt - Smoke library for Qt4

I strongly feel that the Qt4 namespace is most appropriate for this
module. On the other hand, how do we provide a simple upgrade path?

I think Dominique's suggestion based on the Tk bindings is most appropriate:

my $qt = Qt4->new;
$qt->Button .. etc.

We could even have:

$qt->Button->new

or something like that...

What are everyone's thoughts on that sort of interface?

Then I think we satisfy our requirements of:
1. A simple upgrade path from Qt4 -> Qt5 .. etc
2. A method similar to currently accepted Perl practices
3. A thing that doesn't break current use of the Qt3 bindings. From
other discussion on this list it appears that version, however old, is
still in use in some environments.

On the other hand, we can contact Ashley Winters directly (Cc'd to
this mail); if he/she decides that using the Qt namespace itself is
most appropriate, then we can do that. Of course, old versions are
always available via the BACKPAN, for systems that might need them.

The problem arises when the upstream Qt is maintained in parallel -
ie, Qt3 being in long-term support while Qt4 is the preferred version.
In that case, we can't use the standard use Qt '3'; style as was
suggested -- since in Perl it is understood that those parameters mean
"this version or greater" rather than just "exactly this version."

If we go with using Qt4 exactly, then people will always be able to
'use Qt4' and get the right version.

And the way we imitate Tk's interface means that you don't have to go
through the file and change a whole bunch of Qt4 declarations to Qt5
etc. This solves the other concern we had before -- the idea that
having 'use Qt' would be simpler to work with, ie Qt::PushButton->new.
In the interface Dominique suggests, we can do:

my $qt = Qt4->new;
$qt->PushButton->new;

Thus avoiding even having to refer to Qt4 again at all.

Is this something all of the developers can get behind? If so I can
start making changes immediately and commit them to SVN. Also, perhaps
we can plan a weekly meeting or something to discuss outstanding
issues/our resolutions for them.

Cheers,

Jonathan

On Fri, May 29, 2009 at 1:12 PM, Richard Dale <rdale at foton.es> wrote:
> On Friday 29 May 2009 03:35:41 pm Jonathan Yu wrote:
>> On the other hand, releasing that way means we do need to get Ashley
>> Winters to give us control of the namespace. I'm not sure of the
>> likelihood of that given the lack of response with respect to the
>> whole constructor question.
> Umm that doesn't seem correct to me, as Ashley provided a very complete
> rationale for the constructor design, along with examples on this mailing
> list. Did you miss that?
>
>> Right now I do have the Qt4 namespace registered, which means we can
>> use Qt4 and Qt4:: modules. I understand typing Qt4::PushButton might
>> be "ugly", but in the end it's the most Perlish thing to do, and
>> allows easy compatibility with Qt3. Why go through all that work just
>> for some 'pretty' module names?
>>
>> And releasing our inner classes as Qt::PushButton will instantly mark
>> our class as UNAUTHORIZED unless Ashley Winters gives us the entire
>> namespace, which invalidates his/her modules
> Recently, when we wanted to relicense the language bindings based on the Smoke
> libraries under the LGPL, Ashley was very helpful. I've every reason to
> believe he will be helpful again and collaborate with you in your efforts to
> get the current Qt4 PerlQt on CPAN.
>
> -- Richard
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings
>



More information about the Kde-bindings mailing list