Bonjour David, vous dirigez la branche française de KDAB. Pouvez-vous nous dire quelques mots sur cette société et son rôle au regard du projet Qt ?

Bonjour Patricia. Effectivement, KDAB est une société composée exclusivement d'experts Qt. Nous proposons le développement d'applications graphiques en C++ et/ou QML sur Linux, Mac, Windows, QNX, Android, iOS ; l'optimisation de piles graphiques et le déploiement Qt sur systèmes embarqués, la migration vers Qt depuis tout toolkit, l'assistance à distance, le consulting sur site, une gamme de formations Qt et des outils complémentaires à Qt (ex : SOAP).

Notre relation à Qt est d'autant plus étroite que KDAB y contribue beaucoup (environ 10% des changements dans Qt). En effet, KDAB est le mainteneur officiel de QtWidgets, Qt3D, et de certaines classes dans QtCore et QtGui (dont une grande partie du support OpenGL), ainsi que du support cmake.

KDAB prend aussi en charge le portage et la maintenance de Qt sur un certain nombre de plates-formes (Android, Windows CE, QNX, BlackBerry 10...).

Enfin KDAB permet à ses développeurs de prendre une demi-journée par semaine pour se former à toute technologie qui les intéresse, ou pour contribuer à Qt.

Vous-même de quelle manière contribuez-vous à Qt? Maintenez-vous un module ?

J'ai contribué pour Qt 5 au développement de nombreuses nouvelles classes, principalement dans le domaine de la gestion de fichiers, pour les besoins de KDE : QStandardPaths, QTemporaryDir, QMimeType, QSaveFile, QLockFile, QCommandLineParser, et le filtrage d'évènements natifs.

Je suis développeur KDE depuis 1998, ce qui explique ma motivation à faire en sorte que Qt contienne tout le nécessaire pour KDE...

Côté KDAB je me spécialise un peu dans le multitâche : je donne des formations "La programmation multitâche avec Qt", et j'ai apporté des correctifs dans l'utilisation du multitâche dans Qt lui-même.

En ce qui concerne KDE, vous avez contribué notamment au développement de Konqueror. Sur quoi êtes-vous actuellement ? Participez-vous à la migration de KDE vers Qt 5 ?

Ce qu'on appelait KDE auparavant a été découpé en trois morceaux : les frameworks (bibliothèques), le workspace (bureau), et les applications.

Je concentre mes efforts sur le premier morceau, KDE Frameworks.

Il s'agit d'un ensemble de bibliothèques qui s'ajoutent à ce que propose Qt 5, pour fournir des fonctionnalités supplémentaires aux applications. Il y a plus de cinquante frameworks. Pour en citer quelques-uns : KArchive pour le support des formats comme zip, tar, 7zip, gzip, bzip2... ThreadWeaver pour le multitâche avec dépendances entre tâches, Sonnet pour la correction orthographique, Solid pour la détection matérielle, etc.

Ce travail de longue haleine, débuté en 2011, vient d'aboutir en janvier 2014 avec la sortie d'une pré-version de KDE Frameworks 5.

Ma contribution personnelle est cependant en risque de diminution : après avoir été sponsorisé par Trolltech, puis par Nokia, puis par BlueSystems, je suis maintenant sans sponsor et donc réduit à contribuer sur mon temps libre.

"La migration de KDE à Qt 5 nous a permis
de contribuer énormément à Qt 5"

En quoi cette migration vers Qt 5 est-elle importante ?

La migration à Qt 5, combinée avec l'ouverture de Qt aux contributions extérieures, nous a permis de contribuer énormément à Qt 5, ce qui a allégé d'autant les frameworks KDE.

Ceci donne lieu à une migration des applications relativement importante, en terme d'effort, mais le résultat en vaut la chandelle : la fusion du monde des "applications Qt" avec le monde des "applications KDE".

Il n'y aura plus que des "applications Qt", utilisant un certain nombre de bibliothèques Qt (dont certaines fournies par la communauté KDE) selon leurs besoins.

À travers KDAB, vous formez de futurs développeurs Qt. Quel est leur profil ? A-t-il changé avec l'introduction de Qt Quick et du QML ?

Oui et non. Il est extrêmement rare de développer en QML pur. Toute application réelle (autre que exercices et démos) comporte une logique applicative en C++. Le profil du développeur Qt n'a donc pas beaucoup changé, il faut toujours bien connaître Qt/C++, avec en plus les spécificités de l'intégration entre QML et C++, et les spécificités de QML.

C'est donc une technologie qui s'ajoute (et non pas une simplification, pour un expert qui doit pouvoir résoudre les problèmes à tous les niveaux), mais ce n'est pas plus difficile que toute autre nouvelle technologie ajoutée à Qt (graphics view, multitâche, model/view, etc.)

Comment avez-vous vécu le rachat de Qt par Digia ? Qu'en est-il un an après ?

Nous étions à la fois inquiets du fait de l'abandon de Qt par Nokia et heureux que Qt ait trouvé un repreneur, avec la responsabilité de financer la majorité du développement. L'ouverture des contributions à Qt, avec la mise en place de qt-project.org nous avait toutefois rassurés sur l'avenir de Qt, dans le sens où il devenait possible à plusieurs entreprises d'en assurer la survie au lieu de dépendre d'une entité unique.

Globalement nous sommes heureux que le repreneur de Qt soit une entreprise dont la taille, plus modeste que celle de Nokia, est plus similaire à la nôtre, ce qui en fait un partenaire plus accessible et plus compatible.

Un an après, nous sommes contents de voir que Digia réussit apparemment à générer suffisamment de revenus avec Qt pour en financer une partie du développement ainsi que l'infrastructure matérielle, la publication, et la maintenance de Qt.

En ce qui concerne les aspects communauté et marketing, les choses ont beaucoup changé depuis l'époque Nokia. La transition vers Digia avait par exemple soulevé la question de l'organisation des Qt Developer Days, que nous avons pu organiser chaque année depuis, avec la participation d'ICS et Digia.

"Une force de Qt est son côté plaisant
à utiliser pour les développeurs"

À l'heure où le développement mobile devient incontournable, comment se positionne Qt ? Fait-il le poids face à des solutions dédiées ?

La force de Qt a toujours été son côté multiplate-forme. La possibilité d'écrire le code une seule fois pour toutes les plateformes, à part quelques adaptations parfois nécessaires, est un avantage considérable par rapport à l'alternative : réécrire tout pour chaque plateforme.

Ceci couvrait initialement uniquement Linux, Windows et Mac, et l'arrivée des systèmes embarqués, puis des téléphones mobiles, et des tablettes n'a fait que diversifier les plates-formes disponibles, rendant ainsi encore plus important le choix d'une technologie multiplate-forme.

La plupart des systèmes logiciels actuels ne consistent pas seulement en une partie "client de bureau" ou seulement une partie "serveur", mais bien souvent les deux, avec de surcroît une partie "interface mobile". La possibilité de développer tous ces aspects avec une seule technologie est très alléchante, même si certaines sous-parties ont besoin d'être natives sur certaines plateformes.

Comment voyez-vous l'avenir de Qt ?

Qt va continuer à s'étendre, à la fois en termes de marché et de fonctionnalités, confirmant sa position de standard de fait pour les plateformes embarquées et mobiles avec des interfaces utilisateurs riches, pour les développements multiplates-formes performants et intégrés.

Une force de Qt est aussi son côté plaisant à utiliser pour les développeurs (documentation très riche, nommage très cohérent, richesse en fonctionnalités), ce qui en fait un outil de choix pour tout développement applicatif.

Merci pour avoir répondu à mes questions. Souhaitez-vous ajouter quelque chose ?

Avec plaisir, merci pour cette interview. J'en profite pour vous remercier d'avoir fait paraître un livre sur Qt 5, et je souhaite à tous vos lecteurs beaucoup de plaisir en utilisant Qt – et KDE Frameworks :-) .

(17/01/2014)