Nokia Makes LGPL Version of PyQt

EtaCarinae writes "Nokia didn't succeed in convincing Riverbank to change its licensing terms on PyQt, and so decided to create their own LGPL'ed version of it. From the FAQ at the PySide site: 'Nokia's initial research into Python bindings for Qt involved speaking with Riverbank Computing, the makers of PyQt. We had several discussions with them to see if it was possible to use PyQt to achieve our goals. Unfortunately, a common agreement could not be found , so in the end we decided to proceed with PySide.'"

Comments

Kudos to Nokia

[gavron]

If you cannot get the source to open-source, open-source the source.

Kudos to Nokia.

E

Re:Kudos to Nokia

[piquadratCH]

If you cannot get the source to open-source, open-source the source.

PyQt is open source. Or isn't the GPL considered open anymore?

Re:Kudos to Nokia

[Jurily]

Or isn't the GPL considered open anymore?

Not if you want to write commercial software on top of it, which is what Nokia wants to enable. Just as they did with releasing Qt under the LGPL.

It also helps integration if you can get both from the same vendor, and for a project like this, integration is the goal. From now on, you can expect simultaneous and/or bundled releases.

Re:Kudos to Nokia

[piquadratCH]

Or isn't the GPL considered open anymore?

Not if you want to write commercial software on top of it, which is what Nokia wants to enable.

I know the terms of the GPL and LGPL, thank you. I simply think it's unfair to make Riverbank look like the bad guys and Nokia the saviours. Riverbank provided superb Python bindings for a long time and Phil (the guy behind PyQt and Riverbank) offered great support for GPL-users on the mailing list. PySide has a long way to go to offer a comparable experience (just read the blog post on PySide of the main PyKDE developer)

Re:Kudos to Nokia

[Anonymous Coward]

Riverbank provided superb Python bindings

While I'm not disputing the usefulness of their bindings, I'd describe them as "working", but not necessarily "superb". Their API is not very pythonic or concise and feels pretty much like writing C++, without the segfaults :P

Re:Kudos to Nokia

[lokpest]

Not if you want to write commercial software on top of it...

s/commercial/proprietary (or non-free)

The GPL is a commercial license. It clearly permits the licensed software to be sold.

Re:Kudos to Nokia

[Anonymous Coward]

The problem with PyQt was that as it was the only python binding, you had no choice but to pay to riverbank. Considering that they don't own Qt themselves, they got a slight "monopoly"/gatekeeper position on other people's code.

Also, PyQt was not all *that* open source, you couldn't fork it because they only release the generated code.

Re:Kudos to Nokia

[Jurily]

I simply think it's unfair to make Riverbank look like the bad guys and Nokia the saviours.

Nobody wants to make Riverbank look bad. However, Nokia is doing something bigger now: they're gathering all the little pieces you previously needed to find yourself (MinGW, Qt, an IDE, and now PyQT), bundling them up, and releasing them as one package. Open Source GUI programming on Windows has literally never been easier.

My next phone is going to be a Nokia. They deserve it.

Re:Kudos to Nokia

[Jurily]

Now drop the MOC from QT and everybody might consider your platform.

Eh? Moc is crucial for tiny little features like signals and slots (and through that, the event system, and basically everything you want to do with an event-based application). It's the main selling point for Qt. Dropping it would require a complete rewrite, with perhaps QString being the only class that doesn't use it.

Besides, "their platform" already knows about it, and it's completely transparent unless you write your Makefiles by hand.

Re:Kudos to Nokia

[FooBarWidget]

"Not if you want to write commercial software on top of it, which is what Nokia wants to enable. Just as they did with releasing Qt under the LGPL."

Bullshit. PyQT also has a commercial license. You're just being a freeloading leech right now.

Re:Kudos to Nokia

[Anonymous Coward]

I've never worked on Qt, but doesn't the boost signals2 library now offer a superior signals and slots implementation in standard C++? Or does Qt depend on some features not available in the boost signals2 library?

Of course rewriting Qt to use another would be a monumental undertaking and it's probably not worth it merely to improve compatibility with other libraries and toolchains. Nokia seems to agree that can get much more developer mindshare by offering Python bindings.

Re:Kudos to Nokia

[cowbutt]

PyQT also has a commercial license. You're just being a freeloading leech right now.

The availability of commercial licenses for PyQt show that Riverbank has no philosophical objection to people writing and distributing GPL-incompatible code that uses it, but they'd like some money for that use (which is fair enough; they're the authors after all).

Now, Nokia seems to be standardising on Maemo/Qt for their future phones, and part of that is that they'd like to build a viable application marketplace for their phones, a la the iPhone. Keeping it free (gratis) to develop for their platform will encourage developers, which suits their goals. Presumably after asking nicely, they also offered Riverbank some cash or equivalent, at least equal to the costs they eventually incurred in developing PySide. Presumably Riverbank didn't think that was enough, and decline (which is still their perogative).

Re:Kudos to Nokia

[ultrabot]

The point of PyQt is to remain faithful to the official C++ Qt API, making your skills & docs directly transferrable and code easy to port over in either direction.

PyQt has added a new, more pythonic API for signals, and PySide will do the same thing eventually. But it's essential that we retain almost-1:1 C++ mapping (though losing trivial stuff like QString).

Re:Kudos to Nokia

[rohan972]

Just because GPL allows selling commercial software, it doesn't mean that it is very feasible.

I hear that said, yet it happens.
http://ask.slashdot.org/story/09/08/01/169247/The-Ethics-of-Selling-GPLed-Software-For-the-iPhone
http://redhat.com/
http://www.novell.com/linux/

Re:Kudos to Nokia

[Jurily]

You're just being a freeloading leech right now.

Dude, they're bindings from one third-party platform to another. How is it leeching to suggest that a license fully compatible with both of these is a good thing?

Re:Kudos to Nokia

[Jurily]

In addition to providing the signals and slots mechanism for communication between objects (the main reason for introducing the system), the meta-object code provides the following additional features:
QObject::metaObject() returns the associated meta-object for the class.
QMetaObject::className() returns the class name as a string at run-time, without requiring native run-time type information (RTTI) support through the C++ compiler.
QObject::inherits() function returns whether an object is an instance of a class that inherits a specified class within the QObject inheritance tree.
QObject::tr() and QObject::trUtf8() translate strings for internationalization.
QObject::setProperty() and QObject::property() dynamically set and get properties by name.
QMetaObject::newInstance() constructs a new instance of the class.

It is also possible to perform dynamic casts using qobject_cast() on QObject classes. The qobject_cast() function behaves similarly to the standard C++ dynamic_cast(), with the advantages that it doesn't require RTTI support and it works across dynamic library boundaries.

Re:Kudos to Nokia

[Anonymous Coward]

But it's essential that we retain almost-1:1 C++ mapping

Why? I see no point, Python and C++ are two vastly different languages. It's essential that all the capabilities of Qt are exposed, but not necessarily in the exact same form. (ie. fields vs setters/getters, signal/slot objects vs signal/slot strings).

making your skills & docs directly transferrable

Python bindings should be designed to accommodate Python programmers, not C++ programmers.

Anyway, the new signal/slot binding seems nice and indeed what I have been thinking of.

Re:Kudos to Nokia

[FooBarWidget]

"especially if we want to write proprietary code in it"? So you want to make money off someone else's product without ever having to pay him a penny, and you think that's ok? Wow. Just... wow.

It's 2009 and we shouldn't have to pay for whatever proprietary software it is that you're writing.

Re:Kudos to Nokia

[FooBarWidget]

It's leeching because apparently you want to make money off someone else's work without ever having to pay him. After reading your post it's painfully obvious that you only care about it being gratis, not about it being open source.

Re:Kudos to Nokia

[ultrabot]

Hell will freeze over before you'll see Qt embracing GObject. GObject is actually one of the things driving people to Qt.

Re:Kudos to Nokia

[nstlgc]

You'll pay for my software exactly the amount that I'm asking you for it. If not, buzz off and go download somebody else's stuff.

Re:Kudos to Nokia

[ultrabot]

Python bindings should be designed to accommodate Python programmers, not C++ programmers.

I don't think we really want a big divide between Python and C++ programmers. The programming model of C++ Qt programming is not fundamentally broken, so it's not something that needs to be fixed more than what was already done. I'd like to see future breed of Qt programmers proficient wth both C++ and Python, not one over the other (Python isn't "dumb man's c++", it's "busy man's C++"). Both have their place.

Any friendly additions for python programmers can be done over the existing "raw" binding.

Re:Kudos to Nokia

[wowbagger]

Full disclosure:
At work, I have a PyQT commercial license. I've had to look into the licensing issues around Qt and PyQt. The following is based upon my reading of the various licences and issues. I am an engineer, not an IP lawyer, and even were I a lawyer, I am not your lawyer - so do your own research.

I am all for supporting companies like Riverbend who offer both GPL and proprietary licenses.

However, there is a complication that Nokia was trying to address here. Whatever license you are using for PyQT you must also be using for Qt, due to the way they are linked.

Now, with Riverbend, the only licenses they offer are GPL and proprietary. That means that if I want to release a proprietary application using PyQt, I must use the proprietary PyQt. However, that means that I now must use the proprietary license for Qt as well. But that now means I have to buy the developer licenses for my team from Nokia - again, not a big deal from an initial monetary outlay.

Now, for my application I cannot use the GPL license because parts of my application are licensed from other people who don't want to GPL their code - it sucks, and I'd rather not deal with it, but when you are in the RF communications business and you have to support CDMA, you HAVE to do business with Qualcomm, and they will NOT change their minds.

So when I ship my app as a Windows or GNU/Linux application, I cannot use the GPL. Now, just considering Qt, I can use the LGPL - the library is dynamically linked against my code, the user can replace the library, all is right with the world.

Except that I cannot use the LGPL for Qt and use PyQt, as PyQt does not support LGPL. So, in case you cannot draw the Venn diagram for yourself, I am left with using the proprietary license for both Qt and PyQt. Now, even though the licensing terms are pretty generous, I still have to track all the licensed code I ship - so you just added a bunch of cost to my accounting of program. This gets even worse when the program is freely available (remember, you can be free and not be Free).

I had contacted Riverbend when Nokia announced the LGPL'ing of Qt, and at that time they said they were considering it. Obviously, they decided they couldn't do it and remain viable as a business - and while that sucks for me, I can certainly understand their point of view. But without the ability to use the LGPL version of Qt from Python, the utility of Qt is greatly diminished. I can understand why Nokia did what they did. Yes, it would have been nice if Nokia could have worked out a way to fund Riverbend such that Riverbend could have LGPL'ed PyQt, but evidently that couldn't happen.

Re:Kudos to Nokia

[WaywardGeek]

I'm personally a fan of what Nokia is doing. In general, the big GUI libraries need to be LGPL or BSD to gain the widest acceptance. Requiring license fees for non-GPL leaves companies like Nokia flapping in the wind with no solution. This is also why GTK gained so much momentum at Qt's expense. This allows me to learn one way to write code, and to be able to either contribute it to the open-source community (which I do often), or to sell it through my work (which I actually get paid for).

However, this is a troubling new way for a big company to crush a small one... "Give me your technology for free, or I'll rewrite it and then give it to the world for free." It sounds a bit like Microsoft.

Re:Kudos to Nokia

[ceoyoyo]

Writing good wrappers isn't trivial. If what they did was trivial, someone would come along, redo it, and put them out of business. Turns out that, for a long time, their work was worth paying for. It took a company as big as Nokia, with a vested interest, to decide it was better for them to do it themselves.

It's not like you NEED PyQT to use QT.

Re:Kudos to Nokia

[Jurily]

1) complicates the build process

The build process is already needlessly complicated. One more preprocessor won't hurt.

2) pollutes the global namespace terribly (emit, signals, etc.)

"If you're worried about namespace pollution, you can disable this macro by adding the following line to your .pro file:
  CONFIG += no_keywords"

3) slows rebuild as MOC has to inspect the code and regenerate MOC files if needed

gcc is orders of magnitude slower than moc.

4) cannot understand normal and common C++ code (inner class, templates)
6) doesn't know const char * vs. char const * are the same
7) same goes for any other compatible but not strictly-exact prototype

Use the subset that moc understands. Problem solved.

5) causes binding errors that are (maybe not) discovered at runtime

That's a valid point, but what do you recommend to fix it? These errors disappeared when I switched to Qt Creator. There's autocomplete for signals and slots there.

8) adding one more tool/compiler to code generation (to make, compiler, resource compilers, linker..)

Yes, one more. The toolchain is already long, it doesn't matter. Yacc and bison do the same, yet nobody complains.

9) complicates porting to emerging or not supported platforms as you have to port MOC compiler first

Other than "make moc"? Could you show me one instance where moc interfered with porting? If there's a platform where parsing text files can cause problems, why bother?

10) MOC 'invents' its own non-standard non-ISO C++ syntax

That's exactly why I like it: Qt C++ basically looks like a scripting language. And you're not forced to use it, anyway.

11) fragments drive as every MOC dependent file has to be frequently overwritten

You clearly made this one up to make your list longer. How many temporary files do you have in a standard make build?

12) is redundant as Boost already and clearly shows

Qt predates Boost signals. Port both Qt and my applications to Boost and we'll talk.

Re:Kudos to Nokia

[iamwahoo2]

It appears that Nokia most likely wants to bundle the PyQt package into their phones. The problem arises that when the binding is linked against both Python and Qt, the GPL then extends to those products (according to the GNU website). Nokia is a business, if Riverbank had offered their product under a desired license to Nokia at a price that is less than what they could have developed it themselves, then they would have gotten paid for PyQt.

Put yourself in Nokia's shoes. They need a scripting interface to encourage development on their platform. How much would you pay riverbank for a product that does not exactly meet your needs? The GPL is simply not going to work in the phone environment because not everybody is going to want to license their apps under the GPL. The LGPL has proven to be a far superior compromise as evidenced by the fact that Qt (when it was GPL) previously lost traction to inferior products due to their GPL licensing.

Re:Kudos to Nokia

[Eponymous Coward]

How do you know they wanted it for free? Perhaps this has been discussed somewhere, but I don't think the details of the discussion have been made public.

It seems to me that this is exactly what happened years ago before Qt was GPL'd. People were unhappy with the terms of the Qt license and so they made GTK. In the end, I think we are all better off and I have no reason to suspect differently this time. Competition is good.

Re:Kudos to Nokia

[Anonymous Coward]

How did this get modded up to 5? There's no indication anywhere that Nokia demanded PyQt for free.

Re:Kudos to Nokia

[Joutsa]

My current phone is a Nokia (E71), and it's bloody annoying. What they deserve is a kick up the arse.

E71 has Avkon and Symbian. They are pretty impossible to develop for, and it shows in the end result. There is a reason they are switching to Qt, Linux and Python.

Re:Kudos to Nokia

[Kjella]

This is also why GTK gained so much momentum at Qt's expense.

At the same time, what would Qt be without the license income from commercial licenses? Nokia can justify putting money into it to support their products, but Trolltech was a software company. I did look at both GTK and Qt for hobby development and Qt was much higher quality in my personal opinion, and that's because they had real income to hire dedicated developers and make a kick-ass development platform. McDonald's is cheap and popular, that's what GTK is to companies but it doesn't imply that it's good food.

I often find the development of open source projects painfully slow (yes, this is from the and-I-want-a-free-pony-too department) but Qt has always been a positive high note. I love how they take top notch things like WebKit and make them incredibly easy to use in QtWekKit. They're a little bit like Apple, except for developers - they take what's out there and really everybody's doing already but is difficult, package it up in a great way to make it easy for the win.

One thing I really like is that they have, unlike much other open source stuck in the 20th century, embraced long function names and code completion. I just tried to check what the longest function name was and "availableAudioOutputDevicesChanged()" is pretty close. But since it's object oriented, you type the ./-> and the autocomplete list appears. Unlike the fcntl vs iocntl or whatever article that was here recently, it's retarded naming for people still using text editors (let the flamewars begin).

In short, you talk about how much momentum Qt would make, I'm hoping it won't lose any of the momentum it has had. It's basically the standard library C++ should have had to compete with Java/C#...

Re:Kudos to Nokia

[WaywardGeek]

Insightful post! QT wouldn't be where it is without the income it made licensing software, but at the same time, it couldn't dominate because of the license fees. I think Nokia has the kind of deep pockets to really put QT development on track. I think development will accelerate. Of course, I made my bet, and chose QT 4.5 for my company's next product, so now I have a vested interest in QT winning. Further, I'm learning QT, which I feel is about as hard as learning a foreign language (that is, to learn all of QT). By choosing this skill for myself rather than GTK+ or wxWindows, I force myself into a position with a strong vested interest in QT's domination.

Re:Kudos to Nokia

[berj]

I looked at Qt for internal software development at my company. In the end we chose WxWidgets. It was a pain in the ass for years.. but we did it because I wasn't interested in feeding Trolltech's cockamamie pricing scheme. One license per (named) developer per platform? Can only change developers once every 6 months? Ridiculous. We employ co-op programmers who come and go every 4 months. Simply not workable.

I asked more than once for them to sell the product as a package.. a site license or something pro-rated based on the number of developers (1-5, 5-10, whatever).. I also asked them to simply offer a paid yearly support contract which I would gladly buy since our biggest complaint with Wx was the lack of support. No across the board from Trolltech.

So.. we found an alternative.. a free one, as it happens.. but money wasn't the issue.

For the kind of small-scale internal commercial development we do Trolltech's business model was not workable.

Re:Kudos to Nokia

[petrus4]

Some of your arguments sound like the arguments of a religious or political fanatic - sorry.

If there aren't a lot of copies of your work already in circulation, or you're worried about someone making a product out of your work and then removing all trace of the master copy, (which I have seen done in the case of some public domain books, for instance) a copyleft license can be an appropriate choice.

It depends also on what your motivations are. If you have no intention of making money from your work yourself, and simply want to try and ensure that it survives in some form, the GPL is fine. If you want to develop it economically, however, it really isn't the best license.

Red Hat found that out when Oracle started a Linux distribution which included some of Red Hat's own code, which due to the GPL, they legally had to allow. Red Hat are now using the Apache License for JBoss; they got burned, and have learned from the experience.

Re:Kudos to Nokia

[7-Vodka]

You must be genuinely retarded.

How does having the GPL as an option rather than not having it at all inconvenience ANYONE? Also ANYTHING under the GPL can be forked. Don't be a tool.

The only point you can make is that people might refrain from contributing to the project under the GPL because the company can then use their hard work to profit.

Re:Kudos to Nokia

[mweather]

Such as a declarative one.

Such as... ? If it doesn't exist yet, it's not modern, it's futuristic.

Re:Kudos to Nokia

[CAIMLAS]

A bit like Microsoft, yes. But MS would've been more like "Sell/give us your technology for next-to-nothing, or we'll buy someone else's inferior competing software, market the fuck out of it, and ruin you."

Re:Kudos to Nokia

[daveinthesky]

More python apis would be great. If they followed PEP-8, even better.

Describing PyQt as "C++ without the segfaults" is only partially true, though. I've segfaulted the latest PyQt4 (by accident, of course), and it's not too hard to make it happen in different parts of the Qt4 api if you're not too careful.

See, for example:
http://github.com/davvid/git-cola/commit/944ca1252f2f5e6bbd17f8a6fc4718144138bd26

Undo that commit and you, too, can segfault PyQt4 4.5 ;-)

For the curious, there was a change in behavior between PyQt4 4.{3,4} and 4.5. Older versions coped with the original code without a problem. Fedora 11 users reported the problem; my debian install wasn't tickling the bug (probably cos my lib was too old?)

If pyside can help me do away with these workarounds then I'll be quite pleased.

Right now I'm even carrying around setup.py compatibility hacks for older versions of 'pyuic4' that shipped without a proper shebang line. Grr.

I'm sure porting to pyside's going to suck, but if I get a more stable lib then it's worth it. Until they've proven themselves, though, I'll have to deal with the hacks/workarounds[*].

The python guys came up with a py2to3 script for going from python2 to python3. If pyside can come up with a similar script for PyQt4 to pyside then they'll have an easier time winning over existing PyQt4 users.

BTW did anyone else wonder about the name? WTF is pyside? The FAQ doesn't even mention why it has that name.

[*] I know I'll be waiting a bit, though, since Mac and Win support aren't the top item on the pyside todo list a.t.m.

Re:Python and QT going mobile.

[Anonymous Coward]

working towards using QT as a (the) UI-toolkit

If they're going to be using Apple QuickTime as the user interface toolkit, I predict it's going to be a fucking disaster.

Perhaps they should consider using Qt instead.

Nokia Makes LGPL Version of PyQt

[omar.sahal]

Don't forget to give credit where it's due.

OpenBossa is a division of INdT, a nonprofit research institute in Brazil that was founded by Nokia and the Brazilian government. OpenBossa has close ties with Nokia and is well-known in the Maemo community

Taken from the arstechnica web site that also carried this story

Nokia & OSS

[mcelrath]

I'm liking this new approach of Nokia toward open source, with Maemo and Qt. It's a smart move. Python bindings will make for rapid app development. They should soon have armies of OSS developers making apps for their new phone (N900). I must be dreaming, to have both Google's Android and Maemo available on what is historically the most closed computing platform in recent history (cell phones). It seems it will be possible to install both on their new phones. I hope for lots of cross-pollenation, and an app list that puts the proprietary iCrap to shame.

RMS was right, but got one detail wrong.

[ZorbaTHut]

Applications gravitate towards being perfectly open-source. He's right. They do. If there's a closed-source app, eventually someone's going to sit down and clone it to be open-source. They'll do it because they need a version that they can access the source code for, and they'll do it because they're not willing to pay the license fees, and they'll do it because, hey, we went to all this work, why not let other people use it?

He's right.

But the license that code gravitates towards isn't the GPL.

The GPL is restrictive. The GPL is - in some senses - closed, rather than open. The GPL cannot be used for all purposes.

The license code gravitates towards is the BSD license. The MIT license. The libpng/zlib license. The license that says, in brief, "Hey. Here's some code. Don't sue us. Have fun."

Because every software package - every software package - is pushed by that same force, that force that says "I need software with specific allowances, and if I cannot find it, I will make it." And the GPL does not allow everything.

The GPL is a fantastic, amazing license. I've licensed code under it, and I'm glad it exists.

But it's a midpoint - not an endpoint.

Re:RMS was right, but got one detail wrong.

[speedtux]

You're confusing the GPL and the LGPL. The LGPL is a perfectly fine license, and it happens to be what Nokia chose.

The BSD/MIT/... license has specific problems and pitfalls relative to the LGPL; in particular, it raises the possibility of a proprietary fork. Both Apple and Microsoft have made proprietary forks of BSD/MIT-licensed projects, with arguably worse outcomes than if they had been forced to open source under the LGPL.

Re:RMS was right, but got one detail wrong.

[salted-fry]

He's not confusing anything. This story is about Nokia rewriting a GPL library and using the LGPL for the rewrite. His comment about software becoming progressively free-er is entirely relevant.

Re:RMS was right, but got one detail wrong.

[mabinogi]

even close source it and sell it, with no modification

That is utterly false.
The BSD license gives you no right to relicense it. It gives you an unrestricted right to distribute it in source or binary forms, but NOT any right to relicense it.
It also gives you utterly no right to claim it as your own work, in fact, it explicitly states that you must leave the copyright notice intact - the copyright notice which will contain the name of the original author.

The terms of the BSD license are:
You must acknowledge the source by retaining the copyright notice (the GPL requires this too) - either by leaving it in the source, if you distribute source, or by putting it in the docco, or similar if you distribute the binary.
You mustn't use the author's name to promote software based on this software.

If explicitly grants you the right to distribute the source or the binary with or without modification, if and only if those conditions are met.

A company distributing a BSD licensed product that does not include the copy of the BSD license from the product they distributed is in violation of the license.

So when you BSD license your code, you are not allowing people to steal it. You are giving it to anyone to use for any purpose, but they must acknowledge where they got it from. (For as far as their derivative works still meet the Copyright Law definition of derivative work)

Re:RMS was right, but got one detail wrong.

[speedtux]

He is "confusing" it in the sense of using Nokia's GPL-to-LGPL change in order to argue that the "end point" is a BSD/MIT/Apache license. In fact, I would argue that the natural "end point" for licenses is the LGPL, not the BSD license. There are good reasons to rewrite a GPL'ed library in LGPL or Apache form (I have done that myself). But people don't usually rewrite LGPL libraries under BSD/MIT/Apache form, and if they do, there is no reason to believe that the BSD/MIT/Apache version is going to be more successful than the LGPL form. Actually, BSD/MIT/Apache has potential problems from the point of view of long-term sustainability.

The error in his and your reasoning is to view licenses along a 1D continuum and to conclude that because it moves a little in one direction, it will move further. But the 1D view and the assumption of continued motion along it are fiction; there is no evidence for it.

multiplatform?

[jaclu]

Also worth to mention is that this implementation is linux only. Isnt on of the main purposes with languages like python/perl/java that they should be platform neutral?

Re:multiplatform?

[summner]

umm it's open source. You want it to be better ? Contribute ! :]
Nokia is probably focusing right now on the Linux implementation because they want to use it in Linux.
So you know, implementations doesn't just happen by them selves, they need man-hours. So Man-Up and give it to them. But don't whine.

Re:multiplatform?

[Svartalf]

Because Linux isn't just a desktop or server OS...it's a bit more than that.

Symbian's not where Nokia's going, apparently- it's Maemo/Qt. Symbian may be a slightly "tighter" OS where the codespace for the OS is concerned, but coding applications for it is an unmitigated pain.

Maemo's much, much easier and only requires slightly more resources (most of which checked in with the Cortex-A8 class SoC's being fielded for most modern smartphones and handheld devices right at the moment...)- so with the current crop of smart handhelds, it's a winner for them to consider that path. Moreover, it's easier to sell people on making applications (like games, for example...) on the platform than with something like Symbian. The N900 will have versions of the stuff I'm currently porting over to ARM Linux, as will the Pre, G1, etc.

Re:lol delusional BSDtards

[mustafap]

>The only "freedom" it removes is the freedom to harm the freedoms of other users of the software, much like the law restricts your freedom to stab me in the face.

Except that restricting my freedom to "stab you in the face" isn't going to upset many people. But restricting the abilities of companies to develop products that the vast majority of us would like them to make, is.

Re:lol delusional BSDtards

[janwedekind]

Licensing software under GPL does not restrict the ability of companies to develop products. But the GPL does restrict the ability of companies to prevent other competing companies from developing products.

Size and speed

[paugq]

This is what Richard Dale (the main author of SMOKE and the Ruby and C# bindings for Qt and KDE, and C, Objective C and Java bindings in the past, to) said about PySide:

Currently the total size of the PySide libs for all the Qt modueles is 30 Mb. For just QtCore and QtGui they are 22.5 Mb. These are really high figures, and about twice the size of the existing PyQt libs. They are five or six (!) times larger than the Smoke libraries, which weigh in at just over 5 Mb for all the Qt modules. The Smoke libraries can be used by Ruby, C#, Perl, Common Lisp and PHP, not just a single language too. The large size is caused by the heavy use of C++ templates in Boost::Python.

Qt alone has about 500 classes, whereas the current KDE bindings like Python and Ruby wrap over 1500 classes, which would give a combined shared library size of 90 Mb or so assuming the same size per class as Qt. So as PySide stands, I would personally consider that these figures are just too high.

There is a hack in the generate code of doing '#define protected public', to allow protected methods to be called. This certainly won't work on Windows. Fixing it properly will require extra code to be generated to subclass each class with protected methods, and add a public method that calls a corresponding method in the class to be wrapped. This will add some extra code obviously.

It looks like PySide are huge (3x the size of PyQt and 6x the size of SMOKE-generated bindings!) and there is very little improvement they can do if they keep on using Boost::Python to generate PySide.

Given that PyQt costs only £350 (roughly 400 EUR) with full support and is much lighter and mature, I can't see why I would use PySide (unless Nokia gives me full, free, support with my commercial C++ license, of course, which I think they won't be doing because they required you to buy a 1000 EUR separate license for Qt Jambi -the Java bindings- )

Re:Size and speed

[chrb]

I can't see why I would use PySide

Because you won't have a choice if you want to develop for Nokia phones. Nokia will ship PySide as part of the base install and it will be used by their Maemo GUI. Nokia isn't interested in competing with PyQt for that £350 of developer cash - they're interested in shipping millions of QT based Maemo phones with an app store that supports Python applications.

Re:Size and speed

[Just Some Guy]

Given that PyQt costs only ã350 (roughly 400 EUR) with full support and is much lighter and mature, I can't see why I would use PySide

For me, it's partly philosophical. Python is available under a BSD-like license. Qt is available under the LGPL. However, to make Python talk to Qt, you currently have to add the extra restrictions of the GPL. Not to give short shrift to Riverbank, but I thought it was pretty silly that the most restrictive license in that chain was in the glue that connected the more permissive components.

If PySide makes it to Windows soon, this will probably be my company's GUI development platform. I'd always preferred Qt, but GTK's use of the LGPL made it an easier sell to my boss. Thanks, Nokia! I'll remember this next time I'm buying or recommending equipment.

Re:Size and speed

[mairas]

Hi,

I'm the Nokia guy responsible for the project.

It looks like PySide are huge (3x the size of PyQt and 6x the size of SMOKE-generated bindings!) and there is very little improvement they can do if they keep on using Boost::Python to generate PySide.

You're right: the current size of PySide is an issue, especially if you consider mobile environments such as Maemo, let alone the S60 platform. However, that's also why we are working on Shiboken, an alternate binding component which would create CPython extensions directly instead of using Boost.Python as an intermediate layer. Shiboken is still in its infancy, but we expect we'll be able to solve the size issues for once and all, while retaining full Python-level compatibility with the current bindings.

Unfortunately, there's not much info on this yet, but check our repo for the source code: qt.gitorius.org/pyside.

Re:Size and speed

[maceru]

> Unfortunately, there's not much info on this yet, but check our repo for the source code: qt.gitorius.org/pyside [gitorious.org]. Mairas, I have just written some explanations about Shiboken on my personal blog: http://setanta.wordpress.com/2009/08/31/shiboken

Re:lol delusional BSDtards

[nstlgc]

"Shatter his masturbatory fantasies" ? "freedom to stab you in the face" ? "utterly absurd" ? "outright lying" ? "understatement of the millennium [sic]" ? You and your silly hyperbole are poster child for the entire GPL generation.

Re:lol delusional BSDtards

[ceoyoyo]

The LGPL does that. The GPL forces me to offer my software for free, and that may very well be an important factor for a company deciding whether or not to develop a product.

If I don't want to offer my software for free, I may very well write up a library to take the place of a GPLed library. After doing that, I may very well license that library using a BSD/MIT or LGPL license, illustrating the original point, that if licenses tend to evolve toward the GPL then they will continue to evolve toward something even freer.

Re:lol delusional BSDtards

[RedK]

The GPL forces me to offer my software for free

No, it forces you to offer your software for Free. You can charge whatever you want for it.