Dear Pyside2 contributors,

 

As you might know, Pyside was originally developed for Nokia while it was the owner of the Qt technology. When Nokia sold Qt to Digia (and now The Qt Company), all the copyrights over the original Pyside code for Qt 4 got transferred to The Qt Company as well.

 

For different reasons, it was not possible for The Qt Company to push Pyside forward as much as we would have wished over the last few years. Fortunately this changed now, and The Qt Company is today in a position, where it can and will invest into Pyside. The goal is to ensure Pyside becomes a fully supported part of the Qt product family, with a similar development and licensing model as the rest of Qt. We want to make sure Pyside works on new Qt releases when they come out and are committed to invest long term into the technology.

 

To do so, requires us to be able to license Pyside in the same way as Qt itself, ie. under both open-source (LGPLv3) and commercial licensing terms. As you probably know, the Qt Company is doing this for Qt by developing the product together with the community/ecosystem on qt-project.org. The reason that development happens on qt-project.org is that patches pushed to it fall under a contribution agreement (see http://www.qt.io/contributionagreement/), allowing the Qt Company to also have a commercially supported version of Qt, which then funds a lot of the further development of the product. Please note that the contribution agreement is not a copyright assignment, so you as a contributor keep the full rights to the code you developed.

 

Pyside1 has always been hosted on qt-project.org. To make Pyside available for Qt 5 and a fully supported part of the Qt family will require us to develop it on qt-project under the Qt Contribution Agreement. Including the Pyside2 work in this project, would be a great way to kick start it and create a good and open ecosystem around it from the start.

 

We, Christian Tismer and the Qt Company, have already agreed to move Christian’s changes over and to work with the community to achieve this. We would like to ask you as a contributor to Pyside2 to also consider contributing your changes to this effort.

 

We believe there will be many advantages to the Pyside community with this move:

• The Qt Company will commit some developers full time, to help develop Pyside further.
  
• The goal is to make Pyside an integral part of new Qt releases.
  
• Pyside will get a lot more exposure to developers and end users when it becomes part of the officially supported Qt packages
  
• The Qt Company will invest into the required testing, QA infrastructure and people
  
• Full bug tracking through the Qt bug tracking system
  
• The Qt Company will help to make sure that Pyside always works with the latest Qt releases
  
• Of course we will keep Pyside available under open source licensing terms, just as free as Qt itself
  
• Companies who require this can purchase a commercially licensed version of Pyside including commercial support
  
• More exposure and visibility to the people working on and contributing to Pyside 

We sincerely hope you can help us by agreeing to contribute your changes to Pyside2 to this project, so that we can create the best Qt support for Python ever.

 

Please don’t hesitate to ask on this list, if you have any further questions. We would appreciate if you could provide us with feedback on this list or in private.

 

To show your support please create a Qt account under https://login.qt.io/register. Once the registration is complete you can use the Qt account credentials and log into Qt’s codereview tool where you have to accept the Contributor agreement. The acceptance process is described in http://www.qt.io/contributionagreement/.

 

We will then contact each of you individually with details on how to sign off on your own work within Qt’s code review system.

 

Thank you very much.

 

With best regards,

 

Lars Knoll                                            Christian Tismer

Qt Chief Maintainer                             Main Pyside 2 Contributor

CTO, The Qt Company

 

On 2016-04-11 08:13, Lars Knoll wrote:
> For different reasons, it was not possible for The Qt Company to push
> Pyside forward as much as we would have wished over the last few years.
> Fortunately this changed now, and The Qt Company is today in a position,
> where it can and will invest into Pyside. The goal is to ensure Pyside
> becomes a fully supported part of the Qt product family, with a similar
> development and licensing model as the rest of Qt. We want to make sure
> Pyside works on new Qt releases when they come out and are committed to
> invest long term into the technology.

This is great to hear! We have various projects that are still stuck on
Qt4 due to the need for robust Python bindings. While we unfortunately
have not been able to invest directly in PySide2, we're very eager to
see it developed.

Do you expect to retain shiboken, or will you be moving to an entirely
different binding generator? (I've always been partial to shiboken's
design, though obviously it could stand to be ported to clang/llvm...)

--
Matthew

On 11/04/16 21:03, "pysid...@googlegroups.com on behalf of Matthew Woehlke" <pysid...@googlegroups.com on behalf of mwoehlk...@gmail.com> wrote:



>On 2016-04-11 08:13, Lars Knoll wrote:
>> For different reasons, it was not possible for The Qt Company to push
>> Pyside forward as much as we would have wished over the last few years.
>> Fortunately this changed now, and The Qt Company is today in a position,
>> where it can and will invest into Pyside. The goal is to ensure Pyside
>> becomes a fully supported part of the Qt product family, with a similar
>> development and licensing model as the rest of Qt. We want to make sure
>> Pyside works on new Qt releases when they come out and are committed to
>> invest long term into the technology.
>
>This is great to hear! We have various projects that are still stuck on
>Qt4 due to the need for robust Python bindings. While we unfortunately
>have not been able to invest directly in PySide2, we're very eager to
>see it developed.

Thanks. I'm personally really happy that we are now in a situation where we can do this.

>
>Do you expect to retain shiboken, or will you be moving to an entirely
>different binding generator? (I've always been partial to shiboken's
>design, though obviously it could stand to be ported to clang/llvm...)

IMO, that's still an open question that will require some discussion. With Qt 5.7 and onwards we're requiring a C++11 compliant compiler, so it'll become more and more difficult to get things working with the current shiboken. Porting it to clang is of certainly one option.

Cheers,
Lars

On 2016-04-11 16:26, Knoll Lars wrote:

> On 11/04/16 21:03, Matthew Woehlke wrote:
>> Do you expect to retain shiboken, or will you be moving to an entirely
>> different binding generator? (I've always been partial to shiboken's
>> design, though obviously it could stand to be ported to clang/llvm...)
>
> IMO, that's still an open question that will require some discussion.
> With Qt 5.7 and onwards we're requiring a C++11 compliant compiler,
> so it'll become more and more difficult to get things working with
> the current shiboken. Porting it to clang is of certainly one
> option.

Yes, back when I was hacking on shiboken, already the parser was a bit
of a pain point.

I should clarify my comment, however... what I am interested in is
retaining a) a separate binding generator (i.e. that can be used by
projects other than Qt¹) with b) shiboken's features for rejections,
added type conversions, code injections, and so forth. (Bonus points if
the typesystem XML is retained with minimal changes.) This is what set
shiboken apart and above and made it a great tool for other projects to use.

I'm much less concerned what happens on the back end if the final result
is a tool with a similar feature set. In that respect, my question was
poorly worded; what I am wondering is if you expect to retain a similar
architecture for specifying and generating bindings, or to do something
entirely different...

(¹ It would be *truly* awesome if said tool was not itself dependent on
Qt, but that's not critical. Probably not realistic either, since it
will almost certainly need features - e.g. XML parsing - that Qt
provides and would otherwise require alternate dependencies.)

--
Matthew

This is great to hear. Very great to hear! Thanks a lot everyone involved!

On Monday, April 11, 2016 at 5:16:59 PM UTC+2, Lars Knoll wrote:

Dear Pyside2 contributors,

 

As you might know, Pyside was originally developed for Nokia while it was the owner of the Qt technology. When Nokia sold Qt to Digia (and now The Qt Company), all the copyrights over the original Pyside code for Qt 4 got transferred to The Qt Company as well.

 

For different reasons, it was not possible for The Qt Company to push Pyside forward as much as we would have wished over the last few years. Fortunately this changed now, and The Qt Company is today in a position, where it can and will invest into Pyside. The goal is to ensure Pyside becomes a fully supported part of the Qt product family, with a similar development and licensing model as the rest of Qt. We want to make sure Pyside works on new Qt releases when they come out and are committed to invest long term into the technology.

 

To do so, requires us to be able to license Pyside in the same way as Qt itself, ie. under both open-source (LGPLv3) and commercial licensing terms. As you probably know, the Qt Company is doing this for Qt by developing the product together with the community/ecosystem on qt-project.org. The reason that development happens on qt-project.org is that patches pushed to it fall under a contribution agreement (see http://www.qt.io/contributionagreement/), allowing the Qt Company to also have a commercially supported version of Qt, which then funds a lot of the further development of the product. Please note that the contribution agreement is not a copyright assignment, so you as a contributor keep the full rights to the code you developed.

 

Pyside1 has always been hosted on qt-project.org. To make Pyside available for Qt 5 and a fully supported part of the Qt family will require us to develop it on qt-project under the Qt Contribution Agreement. Including the Pyside2 work in this project, would be a great way to kick start it and create a good and open ecosystem around it from the start.

 

We, Christian Tismer and the Qt Company, have already agreed to move Christian’s changes over and to work with the community to achieve this. We would like to ask you as a contributor to Pyside2 to also consider contributing your changes to this effort.

 

We believe there will be many advantages to the Pyside community with this move:

• The Qt Company will commit some developers full time, to help develop Pyside further.
  
• The goal is to make Pyside an integral part of new Qt releases.
  
• Pyside will get a lot more exposure to developers and end users when it becomes part of the officially supported Qt packages
  
• The Qt Company will invest into the required testing, QA infrastructure and people
  
• Full bug tracking through the Qt bug tracking system

...

This is huge!

About that elephant in the room, what will happen to PyQt?

Cool. To use QT5, I just planned to move my project from PySide to Qt, this is a painful process to change python code to C++.

--

This is a really good news. Thanks for all the efforts Christian and Lars. Hope this will be a success.

> Of course we will keep Pyside available under open source licensing terms, just as free as Qt itself

PySide has traditionally been made available such that one could develop commercial projects without paying for a license fee.

The plan is to make PySide2 available "under both open-source (LGPLv3)
and commercial licensing terms"¹. If a project isn't paying for a
commercial license of Qt itself (i.e. can use Qt under LGPL), I wouldn't
expect them to need to pay for PySide either (i.e. can also use PySide
under LGPL).

PySide1 is LGPLv2. If you (i.e. a person/entity developing commercial
software against PySide2) aren't going to "tivo-ize" your software and
don't have patent claims that might infringe against PySide, then I
don't believe the change in license version should matter.

(¹ See the original announcement.)

--
Matthew

This is really cool news. If you are contemplating a Clang-based approach, you might be interested in what I've been brewing over here: https://mail.kde.org/pipermail/kde-bindings/2016-March/008240.html. It would not be hard, I think to retarget, PySide or indeed an abstract internmediate form, that could be used by a binding generator for multiple languages.

Note however that the Python bindings to Clang (which is what I am using) is a bit weak in areas, and so doesn't expose quote enough info in some corner cases. Of course, recursively rebinding Clang is an option, but I have not yet gone there. :-).

Thanks, Shaheed

(I was not aware of shiboken, but it seems some of the goals are similar at least).

Le lundi 11 avril 2016 17:16:59 UTC+2, Lars Knoll a écrit :

Dear Pyside2 contributors,

 

[...]

Good luck...

Thats great news!

What's the status of this?  Did the Pyside contributors sign-up?

Is there any update?

On 5 February 2017 at 04:01, Tony Benoy <tony...@gmail.com> wrote:
> Is there any update?

I would be interested too, to hear about the current status. For now
the only way to get an idea is to look at the git log and the bug
tracker and the weekly "technical" progress log at
http://wiki.qt.io/PySide2 (thanks for keeping that one up-to-date).

Could someone provide a quick status (in words, not git hash or JIRA
ref)? eg., how mature has PySide2 became, how far from "feature
complete", any ETA for a technology preview, online doc deployment on
doc.qt.io, ...

Thanks and hat off to all pyside2 developers and contributors!

Chris

Am 20.02.2017 um 14:48 schrieb Kevin Cole:
> As someone who does not know C++, and is still struggling a lot with
> PySide, my big concern is documentation: The current documentation
> often leaves me with quite a few questions, as it seems often
> auto-generated from the C++ documentation.
>
> So, my hope is that whatever is evolving is evolving with its own
> 'native" documentation.

Even though I don't claim any authority on pyside I think that is unlikely to
happen: The goal of PySide (and other bindings like PyQT/PyGobject+GTK) is to
expose pretty much the native API just in a different language with only very
little pythonic sugar.

The upside is that you can use a lot of QT documentation regarding C++ almost
verbatim and if you look for answers always also look for C++ questions.

While I understand this might be intimidating I found that given a
sufficiently complex PySide/QT application I needed to understand QTs way of
working anyway (sometimes by looking at QT's source code).

Or put differently: Even in Python a serious QT application requires a
significant amount of work so learning a bit of C++ syntax is just a minor
addition in terms of time required.