tag:linuxfr.org,2005:/users/ff9097LinuxFr.org : les contenus de ff90972017-11-24T08:47:18+01:00/favicon.pngtag:linuxfr.org,2005:Diary/375802017-11-13T21:01:14+01:002017-11-13T21:01:14+01:00Apple change la licence de CUPSLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Apple a annoncé le 7 novembre qu'à partir de la prochaine version stable de CUPS (2.3), la licence passera de la GPL v2 vers la licence Apache 2 plus permissive pour eux.</p>
<p><a href="https://www.cups.org/blog/2017-11-07-cups-license-change.html">https://www.cups.org/blog/2017-11-07-cups-license-change.html</a></p><div><a href="https://linuxfr.org/users/ff9097/journaux/apple-change-la-licence-de-cups.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/113091/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/ff9097/journaux/apple-change-la-licence-de-cups#comments">ouvrir dans le navigateur</a>
</p>
ff9097https://linuxfr.org/nodes/113091/comments.atomtag:linuxfr.org,2005:Diary/374072017-07-18T08:27:23+02:002017-08-05T00:47:56+02:00GNOME va passer à GitLabLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Au cours des derniers mois, GNOME a étudié la possibilité de faire évoluer son infrastructure de développement, basé sur le couple cgit‐Bugzilla vers quelque chose de plus moderne, en raison de l’obsolescence de ces derniers (vieillissant, peu d’évolution, peu d’intégration, mauvais <em>workflow</em>…). Au point de faire fuir de potentiels nouveaux contributeurs (personnellement je ne peux que confirmer cela).</p>
<p>Cinq solutions techniques ont été un temps envisagées : GOGS, Gitea, Pagure, Phabricator et GitLab ; rapidement réduites aux deux dernières.</p>
<p>Après une comparaison poussée entre les deux (<a href="https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/FeatureMatrix">voir ici</a>), c’est GitLab qui a été choisi, notamment parce que jugé meilleur du point de vue interface (le fait d’être proche de GitHub fut un avantage), ainsi qu’en raison de la présence d’intégration continue. <br>
[<a href="https://mail.gnome.org/archives/desktop-devel-list/2017-May/msg00051.html">Courriel d’Alan Day</a>.]</p>
<p>En revanche, la communauté est invitée à partager ses commentaires et avis, pour ceux qui ont une expérience de l’outil. Une manière d’essayer d’anticiper d’éventuelles surprises ou points bloquants. Mais on imagine très mal que le souhait soit de rester au temps des dinosaures. </p>
<p>Une <a href="https://gitlab.gnome.org">instance de test</a> a été déployée. À noter que ça semble être la version communautaire qui sera utilisée.</p>
<p>En revanche, la migration complète risque d’être longue et difficile. Des discussions sont aussi en cours pour déterminer le processus. Il semble exclu de migrer tous les bogues de Bugzilla vers GitLab.</p><div><a href="https://linuxfr.org/users/ff9097/journaux/gnome-va-passer-a-gitlab.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/112315/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/ff9097/journaux/gnome-va-passer-a-gitlab#comments">ouvrir dans le navigateur</a>
</p>
ff9097https://linuxfr.org/nodes/112315/comments.atomtag:linuxfr.org,2005:News/374742016-11-21T14:29:32+01:002016-12-18T16:23:03+01:00LibreOffice : de 5.0 à 5.2, un an aprèsLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>LibreOffice 5.2 est publié depuis le 3 août 2016. Cette nouvelle version est destinée aux utilisateurs expérimentés — les autres, comme les entreprises et les administrations, sont invités à utiliser LibreOffice 5.1.6</p>
<p><a href="https://en.wikipedia.org/wiki/Michael_Meeks_%28software_developer%29">Michael Meeks</a> est un développeur qui travaille sur la suite bureautique LibreOffice pour l’éditeur Collabora.</p>
<p>Il vient de publier sur son <em>blog</em> une longue description du travail de refactorisation et de nettoyage qui a eu lieu lors de cette année de développement menant de la version 5.0 à la version 5.2 de LibreOffice. Cette dépêche est une traduction de son article initialement publié dans le domaine public ou licence CC0, comme indiqué au bas de l’article.</p></div><ul><li>lien nᵒ 1 : <a title="https://people.gnome.org/~michael/blog/2016-08-03-under-the-hood-5-2.html" hreflang="en" href="https://linuxfr.org/redirect/97871">Article original</a></li><li>lien nᵒ 2 : <a title="https://wiki.documentfoundation.org/ReleaseNotes/5.2/fr" hreflang="fr" href="https://linuxfr.org/redirect/97872">Notes de version 5.2</a></li><li>lien nᵒ 3 : <a title="http://linuxfr.org/news/libreoffice-5-1-version-majeure" hreflang="fr" href="https://linuxfr.org/redirect/97875">Dépêche de la précédente version (5.1)</a></li></ul><div><h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li><a href="#centre-d%C3%A9veloppeurs">Centre développeurs</a></li>
<li><a href="#la-fin-de-vigra">La fin de Vigra</a></li>
<li><a href="#am%C3%A9liorations-de-lacc%C3%A9l%C3%A9ration-mat%C3%A9rielle">Améliorations de l’accélération matérielle</a></li>
<li><a href="#am%C3%A9liorations-des-performances">Améliorations des performances</a></li>
<li><a href="#rapports-de-crashs">Rapports de crashs</a></li>
<li><a href="#travail-en-cours-sur-la-qualit%C3%A9-du-code">Travail en cours sur la qualité du code</a></li>
<li><a href="#am%C3%A9liorations-du-cycle-de-vie">Améliorations du cycle de vie</a></li>
<li><a href="#tests-unitaires">Tests unitaires</a></li>
<li><a href="#am%C3%A9liorations-de-libreofficekit">Améliorations de LibreOfficeKit</a></li>
<li><a href="#divers">Divers</a></li>
<li><a href="#qa--bugzilla">QA / bugzilla</a></li>
<li><a href="#jenkins--ci">Jenkins / CI</a></li>
<li><a href="#r%C3%A9duction-des-commentaires-en-allemand">Réduction des commentaires en allemand</a></li>
<li><a href="#windowsxp">Windows XP</a></li>
<li><a href="#contribuer">Contribuer</a></li>
<li><a href="#conclusion">Conclusion</a></li>
</ul><p>Aujourd’hui nous publions LibreOffice 5.2.0, la dernière étape de notre voyage, qui sera la base de la toujours plus stable série 5.2.<em>x</em>. Il y a une belle série de nouveautés, faites par des super‐développeurs, qui plairont aux utilisateurs <a href="https://fr.wiktionary.org/wiki/finals">finals</a> (vous pouvez lire les <a href="https://wiki.documentfoundation.org/ReleaseNotes/5.2/fr">notes de version</a> pour vous réjouir), mais, comme toujours, il y a beaucoup de contributeurs dont le travail se fait principalement dans les coulisses et dont les œuvres concernent surtout la technique plutôt que ce qui est visible des utilisateurs.</p>
<p>Il y a quelque temps, l’ESC (<em>Engineering Steering Comittee</em>, le comité de pilotage d’ingénierie) a décidé d’ajouter quelques pages wiki à propos du travail fait sous le capot, pour que les gens puissent ajouter leurs propres crédits. Je vous encourage à lire les pages <a href="https://wiki.documentfoundation.org/UnderTheHood/5.1">5.1</a> et <a href="https://wiki.documentfoundation.org/UnderTheHood/5.2">5.2</a>. Il y a beaucoup de bonnes choses et ça m’évite de devoir lire et résumer les ≃ 10 000 <em>commits</em> de chaque version, même si, là encore, ça peut être drôle. Ceci est ma très rapide tentative pour parler de l’année écoulée au travers des 17 734 <em>commits</em> (ce qui donne environ 50 <em>commits</em> par jour) depuis <code>libreoffice-5-0-branch-point</code> jusqu’à <code>libreoffice-5-2-branch-point</code>.</p>
<h2 id="centre-développeurs">Centre développeurs</h2>
<p>Une excellente initiative de Norbert Thiebaud a été de collecter et centraliser la plupart des infrastructures et leur point d’entrée disponibles au sein de TDF (<em>The Document Foundation</em>) dans une jolie liste afin d’aider les nouveaux arrivants à trouver et utiliser nos outils et services. Jetez‐y un œil : <a href="http://devcentral.libreoffice.org/">http://devcentral.libreoffice.org/</a>.</p>
<p><img src="//img.linuxfr.org/img/687474703a2f2f70656f706c652e676e6f6d652e6f72672f7e6d69636861656c2f696d616765732f323031362d30382d30312d6465762d63656e7472616c2d7468756d622e706e67/2016-08-01-dev-central-thumb.png" alt="Regroupement des sites Web dédiés au développement de LibreOffice" title="Source : http://people.gnome.org/~michael/images/2016-08-01-dev-central-thumb.png"></p>
<h2 id="la-fin-de-vigra">La fin de Vigra</h2>
<p>LibreOffice a été en mesure de fonctionner en mode <em>headless</em> (sans écran ni clavier), en faisant sa propre et longue chasse aux pixels, ce qui est utilisé de manière intensive à la fois par LibreOffice en ligne et aussi par le portage de GTK3/Linux. Ça a été, pour moi‐même et pour d’autres, une source d’étonnement sans fin que le code (illisible) du modèle de Vigra produise un code aussi peu performant dans toutes sortes de cas. Une des grandes joies avec LibreOffice 5.2, c’est la mort définitive de Vigra et du répertoire <code>basebmp</code> et l’utilisation de Cairo en natif (accéléré par l’assembleur) pour la chasse aux pixels. Merci à Caolan McNamara (Red Hat) pour tout ça.</p>
<h2 id="améliorations-de-laccélération-matérielle">Améliorations de l’accélération matérielle</h2>
<p>Pendant cette période, un grand nombre d’améliorations a été apporté à OpenGL et OpenCL :</p>
<ul>
<li><p>Le modèle de rendu d’OpenGL a été fortement simplifié — en effectuant tous les rendus par une texture en <em>back‐buffer</em> à double mise en tampon, puis en les affichant à l’écran à un moment inactif après une requête de rafraîchissement. Il s’agit de la suite des travaux réalisés pour Mac OS X et désormais GTK 3. Combiné avec quelques ajustements dynamiques dans les priorités des rendus, cela donne un rafraîchissement et des redimensionnements doux sans traces. Ce travail a également fortement simplifié la gestion et le cycle de vie des contextes GL.</p></li>
<li><p>Protection contre les crashs d’OpenGL et CL — en raison du grand nombre de problèmes dans la qualité des pilotes — nous avons mis en place une surveillance de chaque appel à GL ou CL — de façon à ce que notre gestionnaire de crashs puisse détecter un plantage lié à ceux‐ci et, dans ce cas, désactiver la fonctionnalité au redémarrage.</p></li>
<li><p>Vérification du comportement d’OpenCL et OpenGL avant leur utilisation réelle, notamment pour éviter des problèmes fonctionnels, en particulier de mauvais calculs dans le tableur.<br>
Ainsi, à chaque changement de version du pilote CL ou de LibreOffice, nous recalculons une feuille de test au lancement et en vérifions les résultats, afin de détecter un mauvais comportement des implémentations CL et pour désactiver, si besoin, l’accélération CL. De même, pour OpenGL, nous compilons par lots et mettons en cache tous nos <em>shaders</em> pour nous assurer qu’il n’y a pas d’erreurs de compilation qui pourraient causer des problèmes plus tard.</p></li>
<li><p>Améliorations de la mise en liste noire d’OpenGL et CL, avec de jolis fichiers <code>cache/opengl_device.log</code> contenant des détails de vos pilotes. Après beaucoup de travail, nous avons découvert que les pilotes GL d’Intel sous Windows 7 étaient incroyablement loufoques et donc ont été mis en liste noire.</p></li>
<li><p>Les performances ont beaucoup été améliorées en combinant les <em>shaders</em>. Il est intéressant de noter que la charge pour passer d’un <em>shader</em> à un autre, ainsi que pour les changements d’état des programmes associés, est très significative. Ce qui fait que l’utilisation d’un seul, et assez compliqué, <em>shader</em> qui gère de nombreux cas est plus rapide que plusieurs <em>shaders</em> très simples (un par cas). C’est pourquoi nous avons fusionné toutes nos routines de dessin texturé et non texturé dans deux gros <em>shaders</em> combinés, qui contiennent un <code>switch()</code>.</p></li>
<li><p>En combinaison avec ça, le travail de groupement et de mise en file pour agréger de nombreuses opérations de dessin en une seule invocation de GL/programme nous confère un avantage indéniable. Combiné avec les améliorations de l’atlas textuel [N. D. T. : ???], ceci nous permet de déférer le dessin d’un grand nombre de glyphes en un seul appel GL.</p></li>
<li><p>D’autres accélérations GL incluant l’utilisation d’un <em>shader</em> pour calculer les <a href="https://fr.wikipedia.org/wiki/Contr%C3%B4le_de_redondance_cyclique" title="Contrôle de redondance cyclique">CRC</a> 64 bits des images (à des fins de comparaison), la mise en cache de nos matrices MVP, et la coordination des transformations spatiales sur le processeur graphique, ainsi que la conversion des dégradés de gris et le rendu des (poly)lignes basées sur les <em>shaders</em>.</p></li>
<li><p>L’absence d’une bonne API pour le rendu matériel des polices de caractères sur Windows nous a poussés à implémenter la prise en charge de <em>DirectWrite</em> pour le rendu du texte. Merci à Tim Eves (SIL) et Martin Hosken (SIL).</p></li>
<li><p>Il y a aussi de nombreuses améliorations et corrections diverses : l’implémentation de « <em>invert</em> », l’amélioration de l’<a href="https://fr.wikipedia.org/wiki/Anticr%C3%A9nelage">anticrénelage</a>, le rendu XOR, la subdivision des polygones basés sur des angles, l’amélioration et l’accélération du <a href="https://fr.wikipedia.org/wiki/Clipping_%28infographie%29"><em>clipping</em></a> [N. D. T. : <em>je crois qu’il s’agit de la découpe du rendu par petits cadres à la façon de Google Map, ça sert surtout pour l’affichage Web</em>], de meilleurs chemins de tests pour <em>vcldemo</em>, l’amélioration du rendu des <em>widgets</em> natifs. Il y a aussi des petits bouts d’amélioration sur les bogues du cycle de vie et du nettoyage fait sur la fermeture, ainsi que de nombreuses corrections de bogues.</p></li>
</ul><p>Merci donc à tous ceux ayant fait plus de cinq <em>commits</em> dans <code>vcl/opengl</code>, <code>opencl/</code> et <code>sc/source/core/opencl</code> : Tomaž Vajngerl (Collabora), Tor Lillqvist (Collabora), Noel Grandin (Peralex), Stephan Bergmann (Red Hat), Caolán McNamara (Red Hat), Markus Mohrhard et Marco Cecchetti (Collabora).</p>
<h2 id="améliorations-des-performances">Améliorations des performances</h2>
<p>Les améliorations des performances sont difficiles à montrer mais sont malgré tout importantes. Nous maintenons des tests de régression de performance (qui tournent sous Valgrind) à l’adresse <a href="http://perf.libreoffice.org">http://perf.libreoffice.org</a>, ce qui aide vraiment à localiser avec précision les problèmes lorsqu’ils apparaissent.</p>
<p>Une belle victoire dans les travaux sur la 5.2 que celle d’Armin Le Grand (CIB) pour améliorer notre gestion des <em>threads</em> et s’en servir pour accélérer le rendu 3D logiciel — ce qui donne une accélération particulièrement notable du rendu des graphiques en 3D.</p>
<h2 id="rapports-de-crashs">Rapports de crashs</h2>
<p>Markus Mohrhard a fait un travail tout simplement excellent sur les rapports de crashs — pour nous aider à trouver les plantages les plus fréquents sur Windows. Alors que de nombreuses distributions GNU/Linux ont des outils similaires déployés depuis des années, couvrir Windows était également important. L’implémentation réutilise <a href="https://chromium.googlesource.com/breakpad/breakpad/">Breakpad</a> de Google pour créer des mini‐vidages de mémoire qui sont analysés côté serveur et joliment tracés sur <a href="http://crashreport.libreoffice.org/stats/">http://crashreport.libreoffice.org/stats/</a>.</p>
<p><img src="//img.linuxfr.org/img/687474703a2f2f70656f706c652e676e6f6d652e6f72672f7e6d69636861656c2f696d616765732f323031362d30382d30312d63726173682d7265706f72742d7468756d622e706e67/2016-08-01-crash-report-thumb.png" alt="Affichage d’un graphique de rapport de Crash" title="Source : http://people.gnome.org/~michael/images/2016-08-01-crash-report-thumb.png"></p>
<p>Markus aimerait l’aide de quelqu’un ayant des compétences en développement Web pour l’aider à améliorer l’interface, et l’analyse, l’interrogation et la présentation des données. Merci de vous signaler sur la liste des développeurs <em><a href="mailto:libreoffice@lists.freedesktop.org">libreoffice@lists.freedesktop.org</a></em>.</p>
<p>Ce travail a déjà permis plusieurs correctifs vitaux pour les crashs les plus récurrents, en utilisant les données adéquates pour remédier aux plus gros problèmes de qualité. Merci à Markus Mohrhard, Caolán McNamara (Red Hat) et Miklos Vajna (Collabora) dont les <em>commits</em> référencent les adresses URL de rapports de crash.</p>
<h2 id="travail-en-cours-sur-la-qualité-du-code">Travail en cours sur la qualité du code</h2>
<p>Il y a du travail en cours sur la qualité du code dans de nombreuses zones, avec au moins 196 correctifs issus de <code>cppcheck</code>. Merci à Caolán McNamara (Red Hat), Julien Nabet, Jochen Nitschke, Noel Grandin (Peralex), Michael Weghorn, Takeshi Abe, Giuseppe Castagno et aux autres.</p>
<p>Caolán et les gars de Red Hat font en sorte de garder le compte d’erreurs de l’analyse de Coverity et le nombre de <em>crash‐tests</em> (charger et sauvegarder ≃ 91 000 documents en plein de formats) à près de zéro tout le temps, en faisant également des tests aléatoires (<a href="https://fr.wikipedia.org/wiki/Fuzzing" title="test à données aléatoires"><em>fuzzing</em></a>) et d’autres corrections.</p>
<h2 id="améliorations-du-cycle-de-vie">Améliorations du cycle de vie</h2>
<p>En poursuivant la refonte du VclPtr [N. D. T. : pointeur sur les objets du <em>toolkit</em> graphique], où nous avons ajouté un robuste cycle de vie référencé à tous nos <em>widgets</em>, Dipankar Niranjan (rapport de bogue TDF nᵒ <a href="https://bugs.documentfoundation.org/show_bug.cgi?id=96888">96888</a>) a nettoyé entièrement le vieil et horrible outil de référencement qui essayait de gérer le cycle de vie correctement à l’intérieur de VCL, en utilisant des références beaucoup plus propres.<br>
Plus récemment, Yurtoglu, Melike Ayse et Noel Grandin ont œuvré à abstraire la <em>VclReferenceBase</em> et à appliquer ça aux menus, afin de s’assurer que leur cycle de vie soit correctement géré. Merci aussi à Jocken Nitschke pour avoir internalisé le <em>DeletionListener</em> (bogue TDF nᵒ <a href="https://bugs.documentfoundation.org/show_bug.cgi?id=97525">97525</a>) qui devrait être supprimé quand un jour nous référencerons et compterons les ressources du <em>back‐end</em> <code>sal/</code> [N. D. T. : « <em>sal</em> » ou « <em>system abstraction layer</em> »].</p>
<p>Il y a un autre travail formidable : avoir exorcisé le comptage de références manuel. Grâce à Thomas Arnhold, Daniel Robertson, Noel Grandin, Aleksas Pantechovskis et surtout Xisco Fauli pour les travaux sur les bogues TDF nᵒ <a href="https://bugs.documentfoundation.org/show_bug.cgi?id=96525">96525</a> et nᵒ <a href="https://bugs.documentfoundation.org/show_bug.cgi?id=89329">89329</a>, qui ont converti de nombreux comptages de référence manuels ou des structures <em>copy‐on‐write</em> pour utiliser l’excellent modèle <em>cow_wrapper</em>. Ils ont aussi converti des pointeurs <em>pIpml</em> pour utiliser <code>std::unique_ptr</code> [N. D. T. : <em>modernisation du code C++</em>]. Ceci réduit l’étendue des erreurs de programmation et des cas particuliers et nous permet de faire des « <em>copy‐on‐write ref‐counting thread‐safe</em> » si nécessaire. Il y a 140 cas corrigés et encore à peu près 68 instances de comptage de références qui ont besoin qu’on s’occupe d’elles.</p>
<h2 id="tests-unitaires">Tests unitaires</h2>
<p>Nous avons continué d’ajouter des tests unitaires critiques cette année. Chacun d’eux permet d’empêcher à jamais la réapparition de régressions. Un <code>grep</code> sur les macros <em>TEST</em> et <em>ASSERT</em> montre que le nombre continue d’augmenter :<br><img src="//img.linuxfr.org/img/687474703a2f2f70656f706c652e676e6f6d652e6f72672f7e6d69636861656c2f696d616765732f323031362d30382d30312d756e69742d74657374732e706e67/2016-08-01-unit-tests.png" alt="Histogrammes représentant la croissance du nombre de tests unitaires, de LibreOffice 3.5 à 5.2" title="Source : http://people.gnome.org/~michael/images/2016-08-01-unit-tests.png"></p>
<p>Notre rêve est que chaque bogue corrigé soit accompagné d’un test unitaire pour l’empêcher de revenir. Avec environ 1 800 <em>commits</em> (20 % en plus par rapport à l’année dernière) et plus de cent contributeurs durant cette période, c’est difficile de lister tout le monde impliqué ici, mes excuses pour cela ; ce qui suit est une liste triée de ceux avec plus de vingt <em>commits</em> dans <code>core.git</code> et <code>online.git</code> : Miklos Vajna (Collabora), Caolán McNamara (Red Hat), Stephan Bergmann (Red Hat), Ashod Nakashian (Collabora), Noel Grandin (Peralex), Markus Mohrhard, Tor Lillqvist (Collabora), Eike Rathke (Red Hat), Michael Stahl (Red Hat), Henry Castro (Collabora), Chris Sherlock, Varun, Andrea Gelmini, Jan Holesovsky (Collabora), Takeshi Abe, Łukasz Hryniuk, Xisco Faulí, Mike Kaganski (Collabora) et ceux avec plus de 10 <em>commits</em> ont aussi droit à une mention honorable — les tests unitaires sont importants ! David Tardon (Red Hat), Katarina Behrens (CIB), Marco Cecchetti (Collabora), Tomaž Vajngerl (Collabora), Oliver Specht (CIB), Zdeněk Crhonek, Mark Hung, Justin Luth, Julien Nabet, Aleksas Pantechovskis, Pranav Kant (Collabora).</p>
<h2 id="améliorations-de-libreofficekit">Améliorations de LibreOfficeKit</h2>
<p>L’API LibreOfficeKit est le fondement de l’application Android, <em>GNOME Documents</em> et le travail en cours sur <em>LibreOffice Online</em>, et beaucoup de choses ont changé l’année dernière. Les deux principaux blocs de construction de l’API LOK sont les méthodes des objets exposés et les types de rappels. Depuis la version 5.0, les nouvelles méthodes suivantes ont été ajoutées :</p>
<ul>
<li>
<code>lok::Office::getFilterTypes()</code> permet d’obtenir une liste à jour de noms filtrés — paire de types MIME, ajouté pour GNOME documents ;</li>
<li>
<code>lok::Office::setOptionalFeatures()</code> et <code>lok::Office::setDocumentPassword()</code> permet d’ouvrir un document protégé par mot de passe ;</li>
<li>
<code>lok::Office::freeError()</code> permet de libérer une chaîne de caractères d’erreur allouée par l’API ;</li>
<li>
<code>lok::Document::getPartPageRectangles()</code> permet d’obtenir la taille et la position des pages d’un document Writer ;</li>
<li>
<code>lok::Document::getTileMode()</code>permet aux clients qui écrivent de travailler avec le nouveau (Cairo) et l’ancien (Vigra) <em>backend headless</em> (voir plus haut) ;</li>
<li>
<code>lok::Document::initializeForRendering()</code> a été étendu pour accepter une option clef‐valeur durant l’initialisation, comme le mode « espaces cachés » de Writer ;</li>
<li>
<code>lok::Document::postMouseEvent()</code> a été étendu pour manipuler les clics et les modificateurs ;</li>
<li>
<code>lok::Document::postUnoCommand()</code> a été étendu pour obtenir un rappel lorsque le résultat d’une commande UNO est prête ;</li>
<li>
<code>lok::Document::getTextSelection()</code> et <code>lok::Document::paste()</code> ont été ajoutés pour manipuler le copier‐coller ;</li>
<li>
<code>lok::Document::getCommandValues()</code> a été ajouté pour pourvoir effectuer des requêtes sur les valeurs possibles pour les commandes UNO (police et nom de style, détails des en‐têtes de lignes et de colonnes de Calc, curseur de cellules Calc) ;</li>
<li>
<code>lok::Document::setVisibleArea()</code>a été ajouté pour pouvoir pour avancer ou reculer d’une page correctement ;</li>
<li>
<code>lok::Document::createView()</code>, <code>lok::Document::destroyView()</code>, <code>lok::Document::setView()</code>, <code>lok::Document::getView()</code> et <code>lok::Document::getViews()</code> ont été ajoutés pour un début de prise en charge de l’édition collaborative ;</li>
<li>
<code>lok::Document::renderFont()</code> a été ajouté pour aider à la prévisualisation des polices ;</li>
<li>
<code>lok::Document::getPartHash()</code> a été ajouté pour aider les clients à suivre la réorganisation des diapos ;</li>
<li>
<code>lok::Document::paintPartTile()</code> a été ajouté pour permettre un rendu sans état de différentes parties d’un document.</li>
</ul><p>Et les nouveaux rappels suivants sont disponibles :</p>
<ul>
<li>
<code>LOK_CALLBACK_DOCUMENT_SIZE_CHANGED</code> : la taille du document a changé ;</li>
<li>
<code>LOK_CALLBACK_SET_PART</code> : le numéro de la partie courante est modifié ;</li>
<li>
<code>LOK_CALLBACK_SEARCH_RESULT_SELECTION</code> : les rectangles de sélection des résultats quand on utilise la fonctionnalité « Tout rechercher » ;</li>
<li>
<code>LOK_CALLBACK_UNO_COMMAND_RESULT</code> : le résultat de l’exécution d’une commande UNO ;</li>
<li>
<code>LOK_CALLBACK_CELL_CURSOR</code> : la taille et/ou la position d’un curseur de cellule a changé ;</li>
<li>
<code>LOK_CALLBACK_MOUSE_POINTER</code> : le style courant du pointeur de souris ;</li>
<li>
<code>LOK_CALLBACK_CELL_FORMULA</code> : le contenu textuel de la barre de formule dans Calc ;</li>
<li>
<code>LOK_CALLBACK_CONTEXT_MENU</code> : la structure du menu contextuel (après un clic droit).</li>
</ul><p>Merci à Andrzej Hunt (Collabora), Ashod Nakashian (Collabora), Henry Castro (Collabora), Jan Holesovsky (Collabora), Michael Stahl (Red Hat), Mihai Varga (Collabora), Miklos Vajna (Collabora), Oliver Specht (CIB) et Pranav Kant (Collabora) pour cela.</p>
<h2 id="divers">Divers</h2>
<p>Un des apports réalisés lors de notre <a href="https://wiki.documentfoundation.org/Hackfest/Ankara2016">Hackfest turque</a> à Ankara fut la découverte que LibreOffice ne se compile même pas avec les paramètres régionaux <code>tr_TR.UTF-8</code>. Il est intéressant de constater que dans cette langue, <code>toupper('i') != 'I'</code> ; amusant (<em>cf.</em> Bogue TDF nᵒ <a href="https://bugs.documentfoundation.org/show_bug.cgi?id=99589">99589</a>). Merci à Krishna Keshav, Gökhan Gurbetoğlu et Apurva Priyadarshi pour les corrections.</p>
<p>Un grand nombre de défauts de l’expérience utilisateur ont été corrigés et améliorés, comme les raccourcis clavier, les problèmes de cohérence de l’affichage, les contrôles mal placés et mal dimensionnés, ainsi que quelques régressions concernant la conversion des fichiers d’interface. Merci à Caolán McNamara (Red Hat), Akshay Deep, Regina Henschel, Maxim Monastirsky, Jürgen Funk (CIB), Bubli Behrens (CIB), Samuel Mehrbrodt (CIB) et Jay Philipps.</p>
<h2 id="qa--bugzilla">QA / bugzilla</h2>
<p>Une métrique que nous regardons lors des conférences ESC, c’est qui est dans le top 10 du <a href="https://bugs.documentfoundation.org/page.cgi?id=weekly-bug-summary.html">résumé hebdomadaire de <em>freedesktop.org</em></a>. Voici une liste de personnes qui sont apparues plus de dix fois parmi ceux clôturant le plus de bogues. Dans l’ordre de fréquence d’apparition : Stuart Foote, Adolfo Jayme, Cor Nouws, Maxim Monastirsky, Eike Rathke (Red Hat), <em>raal</em>, <em>m.a.riosv</em>, Julien Nabet, Caolán McNamara (Red Hat), Miklos Vajna (Collabora), Beluga, Alex Thurgood, Michael Meeks (Collabora), Buovjaga, Yousuf (Jay) Philips, Joel Madero, Samuel Mehrbrodt (CIB), Markus Mohrhard, Timur, Jean‐Baptiste Faure, Xisco Faulí, Aron Budea, <em>tommy27</em>, Michael Stahl (Red Hat), Heiko Tietze, David Tardon, Laurent BP. Avec beaucoup de remerciements pour tous les autres qui ont aidé à clôturer et trier un tel nombre de bogues pour cette version.</p>
<h2 id="jenkins--ci">Jenkins / CI</h2>
<p>Principalement grâce à Norbert Thiebaud, nous disposons désormais, non seulement d’une infrastructure d’intégration continue sous Jenkins, associée à Gerrit, mais aussi d’une ferme de compilation agrandie disposant d’un matériel plus fiable, ce qui encourage les utilisateurs à utiliser Jenkins pour vérifier leur travail avant l’envoi de leur code. Cela se concrétise par une qualité et une fiabilité renforcées de la branche principale. Cette année, nous avons constaté les bénéfices engendrés par notre suite de vérification des tests unitaires sur nos compilations de débogage sous GNU/Linux.</p>
<p>Le travail accompli par Jenkins simplement sur la branche principale pour les six mois de route vers la branche 5.2 : nous avons 34 124 compilations sur Tinderbox couvrant sept configurations sous GNU/Linux, Mac OS X et Windows. Avec 27 737 compilations couvrant ces trois plates‐formes testées sur notre infrastructure Gerrit. Ça, c’est pour le matériel d’intégration continue, il y a de nombreux autres volontaires qui lancent des <a href="http://tinderbox.libreoffice.org/MASTER/status.html"><em>Tinderbox builders</em></a>. Ceci est extrêmement utile pour maintenir la branche <em>master</em> compilable et utilisable, rendant l’arrivée des nouveaux plus facile. Avec 60 000 compilations pour 8 000 <em>commits</em>, nous faisons beaucoup de tests en boucle et de validation du code de LibreOffice au rythme de l’intégration continue.</p>
<h2 id="réduction-des-commentaires-en-allemand">Réduction des commentaires en allemand</h2>
<p>Parmi mes héros préférés, il y a ceux qui clarifient le code pour que les autres puissent travailler dessus. L’une des tâches clefs est la traduction des commentaires en allemand restants (<a href="https://people.gnome.org/%7Emichael/data/2016-08-01-german-comments.txt"><em>liste</em></a>). Les dernières 4 000 lignes semblent défier toute tentative de traduction — je n’ai aucune idée des raisons pour lesquelles ce graphe s’aplatit de la sorte. Tous les correctifs provenant de personnes parlant allemand aimant finir le travail seront grandement appréciés. Un grand merci à ceux qui sont dessus, avec plus de deux <em>commits</em> ; dans l’ordre du nombre de <em>commits</em> : Albert Thuswaldner, Phillip Sz, Thomas Klausner, Chris Sherlock, Philipp Weissenbacher et Matteo Casalin. Il ne reste plus que sept modules à traduire : <em>include</em>, <em>reportdesign</em>, <em>sc</em>, <em>sfx2</em>, <em>stoc</em>, <em>svx</em> et <em>sw</em>.<br><img src="//img.linuxfr.org/img/687474703a2f2f70656f706c652e676e6f6d652e6f72672f7e6d69636861656c2f696d616765732f323031362d30382d30312d6765726d616e2d636f6d6d656e74732e706e67/2016-08-01-german-comments.png" alt="Graphique représentant la réduction du nombre de lignes de commentaires en allemand entre LibreOffice 3.3 et 5.2" title="Source : http://people.gnome.org/~michael/images/2016-08-01-german-comments.png"></p>
<h2 id="windowsxp">Windows XP</h2>
<p>La série 5.2.x tourne bien sur Windows XP, mais nous ne pouvons pas savoir combien de temps nos outils continueront à prendre en charge cette plate‐forme. Notre gouvernance n’a pas de plans concrets visant à supprimer la prise en charge de Windows XP, nous allons le marquer <em>obsolète</em> après la série 5.2.<em>x</em> — ce qui signifie qu’avoir pour base un compilateur C++ moderne et un système d’exploitation Windows moderne est une plus grande priorité. Cela signifie qu’à l’avenir il est possible que les futures versions majeures de LibreOffice ne tournent pas sur Windows XP ; vous êtes prévenus. Pour l’instant, pas de changement à ce niveau.</p>
<h2 id="contribuer">Contribuer</h2>
<p>J’espère que vous comprendrez que de plus en plus de développeurs arrivent et se sentent comme chez eux parmi nous. Nous travaillons ensemble pour réaliser des travaux importants à la fois sous le capot et sur la carrosserie. Si vous voulez vous impliquer, il y a plein de gens compétents à rencontrer et avec qui œuvrer. Comme vous pouvez le constater, les indépendants ont un impact significatif sur la diversité de LibreOffice (la légende des couleurs se lit de gauche à droite, de haut en bas, ce qui représente les couleurs de haut en bas dans le graphique. [N. D. T. : <em>les indépendants, c’est le gros morceau vert au sommet</em>]).<br><img src="//img.linuxfr.org/img/687474703a2f2f70656f706c652e676e6f6d652e6f72672f7e6d69636861656c2f696d616765732f323031362d30382d30312d636f6d6d6974746572732d7468756d622e706e67/2016-08-01-committers-thumb.png" alt="Graphique représentant le nombre de développeurs par organisation" title="Source : http://people.gnome.org/~michael/images/2016-08-01-committers-thumb.png"></p>
<p>Il manque à ces graphiques, générés tôt ce mois, quelques individus et <em>commits</em> mis en attente dans Gerrit pour une revue, d’où le nombre faible en juillet. En termes de diversité, nous adorons voir la quantité de contributions de volontaires non affiliés, bien que le volume et l’équilibre varie selon la saison, le cycle de version, les vacances des volontaires et les <em>business‐plans</em>.<br><img src="//img.linuxfr.org/img/687474703a2f2f70656f706c652e676e6f6d652e6f72672f7e6d69636861656c2f696d616765732f323031362d30382d30312d636f6d6d6974732d7468756d622e706e67/2016-08-01-commits-thumb.png" alt="Graphique représentant le nombre de commits par organisation" title="Source : http://people.gnome.org/~michael/images/2016-08-01-commits-thumb.png"></p>
<p>Naturellement, nous maintenons une liste de petites ou minuscules tâches sur notre page <a href="https://wiki.documentfoundation.org/Development/EasyHacks"><em>Easy Hacks</em></a>, dont vous pouvez vous emparer pour vous impliquer dans ce projet, avec des <a href="http://www.libreoffice.org/community/developers/">instructions simples d’installation ou de compilation</a>. C’est extrêmement facile de compiler LibreOffice. Chaque « <em>easy hack</em> » indique où aller dans le code et représente une tâche simple à résoudre dans un cadre bien restreint. De plus, certaines de ces tâches sont des fonctionnalités vraiment utiles ou des améliorations de performance. S’il vous plaît, envisagez de vous impliquer sur quelque chose.</p>
<p>Autre chose qui aide vraiment : lancer les <a href="http://www.libreoffice.org/download/pre-releases/">préversions</a> et rapporter les bogues. Il suffit de télécharger et d’installer une préversion et vous êtes prêt pour contribuer avec l’équipe de développement.</p>
<h2 id="conclusion">Conclusion</h2>
<p>LibreOffice 5.2 est génial, fait par un groupe de développeurs qui travaillent ensemble avec plaisir à construire une suite bureautique libre de plus en plus belle et attirante. J’espère que vous l’apprécierez. Merci pour la lecture. Et n’oubliez pas de vérifier la page des <a href="https://wiki.documentfoundation.org/ReleaseNotes/5.2/fr">fonctionnalités visibles</a> et merci de soutenir LibreOffice.</p>
<p>Si j’ai raté votre bon travail (car ceci n’est qu’une vue incomplète basée sur quelques heures d’analyse), merci de vous ajouter vous‐même sur la page wiki correspondante et envoyez‐moi un <em>diff</em> de cette page. Merci !</p>
<p>Les <a href="http://people.gnome.org/%7Emichael/data/2016-08-01-data.ods">données brutes</a> et les <a href="http://people.gnome.org/%7Emichael/data/2016-08-01-commit-stats.ods">statistiques de <em>commits</em></a> générées via notre <a href="https://cgit.freedesktop.org/libreoffice/contrib/gitdm-config/"><em>gitdm-config</em></a> sont disponibles pour la plupart des graphiques ci‐dessus.</p></div><div><a href="https://linuxfr.org/news/libreoffice-de-5-0-a-5-2-un-an-apres.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/109712/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/libreoffice-de-5-0-a-5-2-un-an-apres#comments">ouvrir dans le navigateur</a>
</p>
ff9097Yves BourguignonOlivierDavy DefaudBAudjibecfedNils Ratusznikpalm123CraoLucaswindu.2bAxoneSpace_e_manBenoît SibaudariasunikhivapiaChristophebentixXavier CombelleJehanhttps://linuxfr.org/nodes/109712/comments.atomtag:linuxfr.org,2005:Diary/365762016-05-12T14:01:34+02:002016-05-12T14:01:34+02:00Le framework qooxdoo s'ouvre à la communauté :Licence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Qooxdoo est un framework Javascript open-source (licence LGPL+EPL) de développement d'applications web dites “riches” (RIA).<br>
Il se distingue par son orientation orienté-objet (classes, interfaces, mixins, héritage, …). </p>
<p>Ce côté orienté objet permet de facilement garder son code bien structuré et facilement réutilisable même lorsque le projet grossi. </p>
<p>Les interfaces utilisateurs se décrivent via des classes dédiées : dispositions (layouts), conteneurs et bien sur un ensemble de widgets prêts à l'emploi. Il n'y a pas besoin d’écrire HTML ou CSS, c'est du 100% javascript !</p>
<p>Ce framework a été initié et maintenue par l'hébergeur 1&1 pour ses propres besoins pendant des années. Le développement était au point mort depuis quelques semaines et le framework à été libéré à la communauté.</p>
<p>Un travail de migration est en cours pour passer l'ensemble du projet sur GitHub (migration depuis bugzilla, discussions sur gitter.im, tests unitaires sur travis, coveralls.io) afin d’augmenter la visibilité du projet.</p>
<p>Si vous souhaitez contribuer vous êtes les bienvenus, la communauté est restreinte, il est très facile de se faire une place !</p>
<p>Quelques liens utiles :<br>
- <a href="http://qooxdoo.org">Site officiel</a><br>
- <a href="http://github.com/qooxdoo/qooxdoo">Dépôt GitHub</a><br>
- <a href="http://api.qooxdoo.org">API</a><br>
- <a href="http://demo.qooxdoo.org/current/playground/">Bac à sable</a><br>
- <a href="http://demo.qooxdoo.org/current/demobrowser/">Démos</a></p><div><a href="https://linuxfr.org/users/ff9097/journaux/le-framework-qooxdoo-s-ouvre-a-la-communaute.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/108972/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/ff9097/journaux/le-framework-qooxdoo-s-ouvre-a-la-communaute#comments">ouvrir dans le navigateur</a>
</p>
ff9097https://linuxfr.org/nodes/108972/comments.atom