Qt 4.5.0 released (Let the LGPL apps begin) | Hacker News Reader

Qt 4.5.0 released (Let the LGPL apps begin)

labs.trolltech.com

32 pointsicefox9 comments

Does anyone here know anything about whether PyQT is planning on also switching to LGPL? On their license page, they say:

"Like Qt itself, PyQt is provided under a number of licenses depending on how it is going to be used. In fact, we try and follow Trolltech's licensing model as closely as we can."

So I'm assuming that they're planning on switching. Is anyone here on their mailing lists and/or have any other inside information of that sort about whether they're planning on switching?

I would assume they aren't - QT is owned by Nokia so they can afford to give QT away for free just for market share. Riverbank computing (makers of PyQT) is a one man band with bills to pay (it is availabel under the GPL). But if they don't then someone is going to start a community project to produce the swig wrappers themselves.

Having said that - perhaps Nokia might buy Riverbank to keep pyqt going, or Riverbank might feel they can support themselves on consulting/support contracts with a larger installed base of an LGPL pyqt?

You can argue about whether he will or won't - I'm on the "likely will" side - but the only way to know is for Riverbank to say something.

The maintainer of PyQT has said on the mailing list he's "thinking about it", and when I emailed them awhile back I got no answer.

If Riverbank doesn't do LPGL, someone will make LGPL bindings - he would be smart to just do LGPL himself.

The last time I looked at Qt, they had gone mad with the pimpl (private implementation) design pattern, and that made the classes much harder to extend. Needlessly harder to extend in my opinion.

Can anyone tell me if this is still the case?

I suppose it's only an issue if you're really pushing the framework, it shouldn't bother most people.

Not sure I'm expert enough to comment, but doesn't this make it easier to extend a class - because what you can and can't use/rely on is clear?

It's a double edged sword. On the one hand, you know what APIs they've committed to and won't change.

On the other hand, often you want to extend more then they would "allow". And because you're wrapping their APIs, when those APIs change, you should only have to change your code in the one place where you overloaded them.

There's a lot of bad things said about JFC/Swing, I won't repeat them here, but it did allow you to extend almost everything.

And as a side note, GridBagLayout is powerful and elegant, despite what some people say: http://www.youtube.com/watch?v=UuLaxbFKAcc

Yes, it's actually become stronger in Qt 4. Though I don't know quite what you mean with it making them harder to extend. Unless you were planning on doing one of the "#define private public" hacks the "impl" would have been private anyway and not something that you could override.

In 10 years of using Qt, I'm not sure I've ever thought to myself, "Damn, if only that wasn't in the data-pointer." There have been times when something was botched or broken or needed to be overridden when a mechanism wasn't there for such, but that didn't have anything to do with them using a pimpl pattern.

This is really the issue with C++ and not Qt. If you want to keep binary compatibility while improving a library there really are not any other options. With a private class you can have new private variables, virtual functions, function renaming, and well anything goes. But probably something you care more about I have seen on more then one occasion a class completely re-written (for the better). The private class changes completely but the public API stays the same. This would only be possible in c++ with a private class.

Reply on news.ycombinator.com