Voici donc sortie la deuxième beta de PySide, le binding Python de Qt initié par Nokia, dont la principale différence avec le binding historique, PyQt, réside dans la licence : PySide est disponible sous LGPL, une licence moins restrictive que la GPL employée par PyQt. Ainsi, un binding Python de Qt peut être utilisé pour des développements propriétaires sans obligation de payer une licence commerciale.

La première version beta de PySide (la bien dénommée beta 1) apportait un grand changement par rapport aux versions précédents (0.4.2 et avant) : un changement dans l’ABI (Application Binary Interface), ce qui, pour rester en dehors des détails techniques, obligeait à recompiler toute application se basant sur PySide (notamment le module Python). Cependant, ainsi, le projet se dote d’une architecture qui pourra servir pendant encore un certain temps, enlevant les choix de conceptions qui se sont avérés moins bons que d’autres.

La beta 1 améliorait le support de Qt Quick et de QML, les interfaces utilisateur dans ce langage déclaratif étaient désormais possibles en Python ; une seule chose manquait : l’enregistrement de nouveaux types QML depuis Python. Cela est désormais possible, comme l’atteste l’exemple : http://qt.gitorious.org/pyside/pyside-examples/trees/master/examples/declarative/extending/chapter5-listproperties.

Le support de Python 3 a été déclaré comme « non insurmontable » mais est prévu pour après la sortie de la version finale de la branche 1.0. Il est à remarquer, à ce niveau, que PyQt supporte déjà Python 2.x et 3.x, mais propose à chacun des API différentes, l’API 1 est plus prévue pour le portage d’applications du C++ au Python (par défaut pour Python 2.x), l’API 2 étant plus pythonique (par défaut pour Python 3.x), ce qui n’est pas très cohérent. Le PSEP 101, déjà implémenté, fait le choix de ne se baser que sur l’API 2, car plus pythonique ; ce choix permettra de passer sans trop de dégâts dans son code à Python 3.x.

Afin de fignoler le travail, au moins deux betas sont prévues avant cette version finale (trois semaines avant la beta 3, puis deux semaines pour la beta 4 et deux nouvelles semaines pour la finale, tels sont les projets).

Sur les quelques derniers mois, des contacts ont eu lieu entre les développeurs de Qt et Canonical ainsi qu’avec les participants au projet Ubuntu. Mark Zimmerman, CTO de Canonical, disait sur son blog, en octobre :

I have been thinking about Qt recently. We want to make it fast, easy and painless to develop applications for Ubuntu, and Qt is an option worth exploring for application developers. In thinking about this, I’ve realized that there is quite a bit of commonality between the strengths of Qt and some of the new directions in Ubuntu.

Overall, I think Qt has a lot to offer people who want to develop applications for (and on) Ubuntu, particularly now. It already powers popular cross-platform applications like VLC, not to mention the entire Kubuntu distribution. I missed it when this happened last year, but Qt is now available under either the LGPL 2.1 or the GPL 3.0, which should make it suitable for virtually any Ubuntu application. It has strong commercial backing as well as a large developer community.

J’ai pensé à Qt récemment. Nous voulons que le développement d’applications pour Ubuntu soit rapide, simple, sans anicroche, Qt est une option qui mérite d’être explorée pour les développeurs. En pensant à tout cela, j’ai trouvé qu’il y avait quelques points communs entre les forces de Qt et les nouvelles orientations d’Ubuntu.

En général, je pense que Qt a beaucoup à offrir à des gens qui veulent développer pour (et sur) Ubuntu, particulièrement maintenant. Il est déjà à l’Å“uvre dans des applications multiplateformes comme VLC, sans oublier la distribution Kubuntu dans son entièrement. Je ne l’avais pas remarqué l’année dernière, Qt est maintenant disponible en LGPL 2.1 ou GPL 3.0, ce qui le rend utilisable pour à peu près toute application Ubuntu. Il possède aussi un support commercial et une large communauté de développeurs.

Et de citer plusieurs points communs, dont les plateformes supportées. Qt supporte depuis longtemps ARM comme x86, depuis plus de dix ans ; Ubuntu supporte les produits basés sur ARM depuis deux ans, la dernière version supporte encore plus de processeurs ARM ; de son côté, Qt optimise son utilisation de ARMv7, la dernière version de l’architecture. Ainsi, on peut fournir aux fabricants un large choix de matériel sans sacrifier la gamme de logiciels disponibles.

Par la suite, deux développeurs de Qt, Zeno Albisser et Dennis Dzyubenko, ont été personnellement invités à la Ubuntu Developer Conference 2010, qui a eu lieu à Orlando. Ils avaient pour but d’aligner la stratégie de Canonical pour le support d’Ubuntu et des services liées avec Qt, ont participé à différentes discussions sur les gestes et les méthodes d’entrée multipoint. Bien évidemment, ils brandissaient le drapeau Qt ! Selon Zeno, Canonical est très intéressé par l’approche de Qt pour utiliser la puisse de l’entrée par des gestes (taper, taper et maintenir, balayer, etc.).

La vérité, cependant, est que rassembler deux communautés, deux flux de développement n’est jamais une mince affaire, même si les deux groupes sont de bonne disposition dès le tout début. Quand il s’agit d’en venir au niveau de la technologie, Zimmerman avait déjà suggéré que travailler ensemble pour activer le support des gestes d’une manière collaborative sera un processus assez complexe. Il disait même que Qt avait un système d’entrée tactile très mature, avec maintenant le support du multitouch et des gestes, dont QML (fairly mature touch input system, which now has support for multi-touch and gestures (including QML)), il est donc de ceux qui voudraient aligner les développements de la communauté Canonical vers les outils offerts par Qt. Cependant, ces fonctionnalités ne sont complètement implémentées et supportées que sous Windows 7 et Mac OS X 10.6, rien pour Linux et X11 pour le moment (bien qu’un développement d’un framework de bas niveau pour ces plateformes soit en cours de développement).

Du côté de Qt, l’objectif est de travailler dur, avec un peu de magie et de chance si nécessaire, pour aller plus loin dans la collaboration avec Canonical et Ubuntu, pour que tous partagent le même framework.

Mais est-ce une si bonne nouvelle ?

Sources : http://blog.qt.nokia.com/2010/12/22/my-new-years-resolution-plus-canonical-and-the-opportunity-to-work-more-closely/ et http://mdzlog.alcor.net/2010/10/20/ubuntu-and-qt/