URL: https://linuxfr.org/news/javascript-comme-langage-par-defaut-pour-gnome Title: Javascript comme langage par défaut pour GNOME Authors: Anonyme rootix, patrick_g, baud123 et Florent Zara Date: 2013年02月04日T10:39:32+01:00 License: CC By-SA Tags: fosdem, lennart_poettering et firefox Score: 49 Les développeurs GNOME se sont rassemblés pour proposer des solutions afin d'améliorer l' _expérience des développeurs_. Dans la suite des annonces sur GNOME 4.0 et la volonté de fournir un SDK stable et accessible, cette édition est centrée sur l'expérience des nouveaux développeurs d'application tierce. La question centrale est : « Quel processus depuis l'ouverture de mon éditeur jusqu'à l'installation de mon application par des utilisateurs ? ». Opération séduction donc, pour GNOME qui veut devenir une plateforme plus attractive pour les développeurs d'applications. ---- [Retours de l'événement sur le wiki de GNOME](https://live.gnome.org/DeveloperExperience/Hackfest2013) [ECMAScript 6](http://www.synbioz.com/blog/ecmascript_6) ---- Le souci de plaire aux développeurs n'est pas nouveau au sein du projet GNOME. Dès son origine, le développeur doit pouvoir écrire une application GNOME dans le langage de son choix. Ce fut un des objectifs de GObject puis de GObject introspection, un des fondements de la plateforme GNOME. Aujourd'hui que les bases techniques sont là, c'est une approche globale qui est recherchée pour multiplier les applications GNOME. L'idée est donc de fournir *une* solution officielle et unifiée aux problématiques du développement d'application, sans exclusive. # Le Hackfest L'événement s'est déroulé à Bruxelles, capitale de la Belgique et haut lieu du logiciel libre grâce notamment au [FOSDEM](https://fosdem.org/2013/). Une trentaine de développeurs se sont réunis, y compris des développeurs du noyau comme Greg Kroah-Hartman ou des trolleurs comme Lennart Poettering. À l'instar de la conception de l'interface utilisateur, les développeurs GNOME ont commencé la réflexion par analyser l'État de l'art dans la concurrence : SDK iPhone, OS X, Firefox OS, Androïd et Windows. # Outils de développement Une des premières questions est : avec quoi coder ? Le projet GNOME propose plusieurs IDE, principalement [Anjuta](http://projects.gnome.org/anjuta/) et [MonoDevelop](http://monodevelop.com/) pour les plus actifs. Mais [Emacs](http://www.gnu.org/software/emacs/), Vim ou même [Gedit](http://projects.gnome.org/gedit/) restent des choix répandus. Question restée ouverte. Des idées ont émergé comme livrer des jeux d'extensions pour Emacs ou vim intégrant Devhelp, glade et d'autres outils incontournables pour le developeur GNOME. ![GtkParasite](http://chipx86.github.com/gtkparasite/images/screenshots/signals.png) Un deuxième aspect est le débuggage. C'est actuellement difficile de debugguer des interfaces en Gtk. Pourtant, des initiatives existent comme [GtkParasite](http://chipx86.github.com/gtkparasite/), un inspecteur à là [Firebug](https://addons.mozilla.org/fr/firefox/addon/firebug/). Ce genre d'outils gagnerait à être intégré et supporté dans la plateforme de développement. D'autres utilitaires de débuggages DBus, GObject, etc. gagneraient à avoir plus de visibilité. # Documentation On ne peut pas se contenter de lire le code des autres. Le récent travail de fond sur http://developer.gnome.org/ va être poursuivit. il faut reconnaître la tâche considérable accomplie par des projets [OPW](https://live.gnome.org/OutreachProgramForWomen) pour documenter le développement d'application GNOME. Outre les discussions, du code a été écrit durant l'événement. L'application de navigation dans la documentation − Devhelp − a commencé sa migration vers l'ergonomie GNOME 3. Portage vers gsettings, python3 et webkit2 et une tripotée de corrections de bugs. Le menu d'application est utilisé, mais la barre de menu de fenêtre persiste. ![Devhelp 3.7.5](http://bersace.cae.li/pub/linuxfr/devhelp-3.7.png) # Plateforme et Javascript Une décision importante a été prise par les membres de ce Hackfest : le *choix du langage par défaut* pour le développement d'application GNOME. Attention, il ne s'agit pas de réécrire les programmes existants dans un nouveau langage. Actuellement, le C est utilisé pour documenter la plateforme, car c'est la langue native des bibliothèques. Il faut présenter un langage de haut niveau pour le développement d'applications. ## Pourquoi mettre en avant un langage ? La question n'est pas nouvelle. Havoc PENNINGTON avait déjà abordé le sujet à l'époque de la sortie de la plateforme .NET. Le choix était plutôt [Java, Mono ou C++ ?](http://ometer.com/desktop-language.html) et Havoc était un peu seul à se poser cette question. Voici quelques raisons qui ont poussé les développeurs GNOME à se poser cette question : - La majorités des applications sont écrites dans un langage de plus haut niveau : python, vala, javascript, perl, C#, etc. Peu sont écrites en C ou en C++. - La documentation de la plateforme est en C, de fait les documentations dans les langages de haut-niveaux sont en retard, alors que GObject introspection a supprimé le retard des passerelles. - Harmoniser la documentation de la plateforme autour d'un langage simple et accessible. - Aider les nouveaux développeurs à se lancer. - Faciliter le partage de code entre les développeurs. - Garantir un environnement pour le développement rapide : passerelles vers les bibliothèques, documentation, debuggers, etc. Mettre en avant un langage n'est pas rejeter les autres, au contraire. Le but est justement que l'utilisation première des bibliothèques de la plateforme se fasse à travers des passerelles. Hors GObject Introspection est utilisé pour tout les langages. C'est donc un gain pour tous les langages de haut niveau que d'en avoir un mis en avant. ## Quelles contraintes ce langage doit-il satisfaire ? - Paradigme objet, dynamique, de haut niveau. - Permettre le REPL : read-eval-print-loop. - Répandu hors de GNOME. - Intégrable facilement avec la plateforme GNOME, sans fournir de doublons standard. Vala n'est donc pas choisit, cependant il a de beaux jours devant lui comme langage de choix pour écrire des bibliothèques. Python est également exclu car il fournit déjà une énorme bibliothèque standard, redondante en partie avec la plateforme GNOME. *C'est finalement Javascript qui a obtenu le plus large consensus*. En voici quelques raisons : - Réponds aux critères ci-dessus. - Les développements récents en font un langage rapide et indépendant de la plateforme. - Très répandu, de plus en plus en dehors du web avec Windows 8. - Déjà fait ses preuves avec GNOME Shell et GNOME Document. Concrètement, les nouvelles applications GNOME seront en javascript, à l'instar de GNOME Document. Les autres ne devraient pas migrer sauf avis du mainteneur. Ainsi GNOME Contact restera en Vala. Les réactions n'ont pas manqué. Javascript est un langage à prototype, n'est-ce pas étrange pour utiliser GObject ? Les interprêteurs javascripts sont variés et incompatibles. Beaucoup de développeurs ont une mauvaise opinion de javascript, souvent justifiée. L'avenir confirmera si ce choix est judicieux. En tout cas, ce n'est pas la mode qui a dicté ce choix. Javascript est déjà utilisé intensivement par GNOME. [ECMAScript 6](http://en.wikipedia.org/wiki/ECMAScript#ECMAScript_Harmony_.286th_Edition.29) − nom de code Harmony − devrait résoudre nombres de réticences. L'ajout de `class`, `extends`, `super`, des valeurs par défaut des arguments, des modules, les chaînes sur plusieurs lignes, etc. Les développeurs python devraient retrouver un peu de calme avec tout cela. Mais quand ? On avance l'horizon 2014... en attendant il y aura des mécontents ! ## Et Gtk+ ? Le choix de javascript ne doit pas occulter les questions autour de Gtk+ lui-même. En vrac : - Fournir un widget adapté pour les nouvelles vues en grille de l'ergonomie GNOME 3. Étonnant que ça ne soit pas déjà fait... - Gestionnaire de scène pour les applications par étapes, avec différentes pages. Façon application téléphone. Actuellement, on utilise un notebook sans onglets pour basculer d'une vue à l'autre. - Alignement des widgets sur la ligne d'écriture, et non sur les limites. Très pratique pour aligner les champs et les étiquettes. D'autres hacks dans les applications existantes montrent des limites dans Gtk+. # Conclusion Ce hackfest est un tournant pour définir GNOME comme une plateforme. Les décisions importantes et l'augmentation du nombre de participants montrent un projet en bonne santé côté développeurs, mais les fruits ne sont pas encore visibles : GNOME 3 est toujours le parent pauvre sur Ubuntu, les utilisateurs de GNOME 3 sont encore peu nombreux, la communauté des développeurs occasionnels encore plus ! À confirmer donc !

AltStyle によって変換されたページ (->オリジナル) /