tanguy_k a écrit 766 commentaires

[ndlr : sous Linux] Beaucoup de logiciels viennent en binaire compilés en statique

Pour quelques logiciels oui (Firefox, LibreOffice, Clementine); pour tout le reste il n'y a rien : qBittorrent, Transmission, VLC, SMPlayer, Amarok, Abiword, Ekiga, Geany, GIMP, GParted, Inkscape… et pour les applis GNOME/KDE c'est encore pire.

=> ~90% des applis Linux ne sont pas dispo en binaire sur le site web de l'appli.

L'exemple de VLC est typique : la page de download redirige vers les distribs et leurs backports.

Pourquoi ?

Parceque c'est compliqué pour l'auteur du logiciel de fournir (et tester) des binaires pour la myriade de distributions et formats de package.

Impact sur l'utilisateur

"il utilise des anciennes versions de ces logiciels" ou il doit upgrader sa distrib (si pas de backport) ou il doit compiler le code source - inacceptable pour un utilisateur de base et perte de temps pour les autres.

pasBill pasGates le résume très bien : "J'ai une distrib, je veux installer un soft récent qui n'est pas dans mon dépôt, c'est l'horreur […]"

Pourtant c'est une "fonctionnalité" de base de tous les OS grand public (Windows, OS X, Android, iOS) : mettre à jour facilement un logiciel sans mettre à jour l'OS.

Impact pour l'auteur du logiciel

"les développeurs ont peu de retours utilisateurs sur la version courante".

Solution

Un bon début serait de standardiser et populariser un seul format de package et ensuite de pousser cette standardisation au delà.

Ça n'arrivera jamais parceque "la diversité c'est génial" ®, et GNU/Linux continuera de plafonner à 1.5% de pdm.

encore faut-il réussir à l’installer !

C'est bien ça le problème. On ne peut pas simplement aller sur le site web (ou sur un store), télécharger la nouvelle version qui vient de sortir et l'installer en un clic.
Il faut attendre que le logiciel soit intégré à la distribution puis mettre à jour toute la distrib sur sa machine ou utiliser un backport s'il existe.

Et ceci est valable pour (presque) toutes les applications sous Linux.

Du coup l'utilisateur utilise des anciennes versions de ces logiciels et les développeurs ont peu de retours utilisateurs sur la version courante.
Effet pervers supplémentaire, certains bugs sont du au packaging de l'application par les distribs (qui souvent patchent les applications pour rajouter à la confusion).

développer pour tablette Windows 8 sera plus facile !

Pas avec Qt Quick pour le moment malheureusement : http://qt-project.org/wiki/Qt-5-on-Windows-8-and-Metro-UI http://stackoverflow.com/questions/11682027/will-windows-phone-8-support-qt

• As-tu testé ta démo sous Android et iOS ? ça fonctionne correctement ?
• Quelles sont les raisons pour ne pas passer à HTML/JavaScript/WebGL ?
• Le débat sur les Femen avec Laurent Ruquier en volume très faible dans la vidéo est passionnant :)

Je pensais que tu parlais d'ajouter une nouvelle implementation de la VCL pour Qt
[…] Je pensais qu'alors il faudrait avoir une implementation Qt complete de la VCL avant de pouvoir l'utiliser

Un backend Qt pour VCL pourrait être aussi une façon de passer progressivement vers Qt. C'est même, pourquoi pas, 2 approches complémentaires.

En plus des mélanges Qt/MFC, Qt/Motif…, il est possible de mélanger du code Qt avec Glib et probablement même du code Qt avec du GTK+.

Glade [..] permet de facilement concevoir des propositions d'interfaces. […] Qt a Qt designer dans le meme registre.

Glade et Qt Designer existent depuis la fin des années 90. Ce que propose Qt Quick/QML est d'un tout autre niveau.
De plus contrairement à ce qu'on pourrait penser, les perfs sont excellentes ! : http://tolszak-dev.blogspot.fr/2013/02/simple-qml-vs-efl-comparison.html

j'ai bien peur qu'un portage vers Qt ne soit pas dans le radar actuellement

AMHA ça n'arrivera jamais :/

Quand la suite bureautique Calligra sera disponible en version Qt 5 (et grâce au travail sur KDE Frameworks 5), celle-ci tournera logiquement sans "hacks" sous Windows et OS X et profitera ainsi peut être d'un regain d’intérêt et d'une visibilité plus grande (au même titre que d'autres applications KDE comme Amarok, Kate, KMail, Okular…)

En attendant tous mes clients travaillent avec MS Office et j'ai jamais vu l'un d'eux utiliser LO.

l'inertie du code l'emporte sur la migration vers une nouvelle librairie

Tout le monde a bien conscience que c'est compliqué de changer, que ça prends des années.
Qt permettrait de le faire par étapes en se mélangeant au code historique.
Ça c'est déjà fait pour les MFC, Motif et Java AWT/Swing.

quel serait l’intérêt pour eux de le faire ?

On tourne en rond là…

Utiliser un toolkit comme Qt permet d'externaliser beaucoup de code à des gens dont c'est le métier, qui ont le temps, les compétences et les ressources pour le faire beaucoup mieux que toi.
Ça permet de te concentrer sur l'essentiel, sur ton cœur de métier qui n'est pas de développer et maintenir une librairie graphique complète.

Et les arguments du type "une nouvelle librairie que tu ne connais pas" et "tu ne maîtrises pas l'évolution" tiennent plus de NIH qu'autre chose. On parle de Qt hein : LGPL, open gouvernance, très bien documenté ect…
Subsurface, VLC, Wireshark, LXDE, OpenShot, Stellarium, Autodesk Maya, Ubuntu Unity, TortoiseHg… ont bien réussis à changer pour Qt.

Que va t'il se passer s'ils continuent avec leur toolkit interne ?

• Le toolkit va continuer de vieillir gentiment : moins jolie que la concurrence, widgets pauvres, pas d’accélération, pas d'animation, moins bonne intégration avec les futurs versions de Windows, OS X…
• Temps consacrer à la maintenance et à l’évolution de VCL
• Temps de développement important pour ajouter/améliorer des fonctionnalités à LO : exemple de rapidité de développement avec Qt : http://www.youtube.com/watch?v=_6_F6Kpjd-Q, je doute que ça soit aussi rapide et facile avec VCL…
• Rebuter les potentiels contributeurs : les gens connaissent les toolkits couramment utilisés, pas VCL
• Difficultés de portage sur d'autres plateformes (Android, iOS, FirefoxOS… je parle pas du POC présenté ici : http://arstechnica.com/information-technology/2013/03/libreoffice-for-android-frustratingly-close-to-release/ mais de vrais applications utilisables au quotidien)
• …

J'ai travaillé dans des entreprises qui n'ont pas toujours fait évoluer leurs outils et librairies : build system custom en Perl, librairie graphique développée en interne, base de données interne…
Ces outils avaient un intérêt 10-15 ans auparavant mais sont devenu un frein important par la suite.

En revanche on est bien d'accord que la priorité est de nettoyer le code avant de pouvoir faire un changement de cette importance. Mais apparemment remplacer VCL pour Qt n'est clairement pas à l'ordre du jour :-/

Et ce n'est pas parceque je ne contribuerais probablement jamais à LO que je n'ai pas le droit de faire des analyses à son sujet.

VCL n'est qu'une couche d'abstraction vers les les libs qraphiques des OS

Tout comme wxWidgets, AWT, SWT et dans une moindre mesure GTK+, Qt, SWING…
Ta négation "n'est qu'une […]" sous entends que c'est facile alors que ça ne l'est absolument pas.

Tu m'as l'air bien motive, vas-y, lance toi

Remarque récurrente pour éviter de répondre à toute critique.

Parce que convertir toute la suite à Qt est un travail de titan ?

Plus que maintenir un toolkit entier (VCL) sur 3 plateformes ?

Du code Qt peut très bien vivre avec du code fait avec autre chose. Le travail peut se faire au fur et a mesure.

Glade, automake/autoconf… vue de l’extérieur en 2014, les choix technologiques sont tout de même étonnants.

Une bonne intégration ne se limite pas à avoir le même style et à avoir la bonne boîte de dialogue pour les fichiers.

C'est deja un bon debut :)

Je pourrais citer en vrac

Es-ce que Qt (ou un autre toolkit multi-plateformes) le fait/le permet facilement ?

Oui c'est vrai, j'avais complètement zappe cet aspect la !

Ou peut-être aussi qu'il n'y a pas tant de gens qui râlent par rapport à la masse totale d'utilisateurs.

Ou peut-être aussi qu'il n'y a pas beaucoup d'utilisateurs.

1% du marché fragmenté entre Unity, GNOME, KDE, Xfce, Cinnamon, MATE… ils restent quoi ?
=> Les devs de GNOME, qqs geeks et utilisateurs de base qui utilisent 99% du temps leur machine pour surfer et qui en ont rien a battre que ca soit GNOME, KDE ou Xfce.

Je pensais à Qt vs toolkit iOS/Android (qui sont desormais bien etablies et maitrises).

Pour Firefox OS, les qqs retours utilisateurs sont malheureusement tres mauvais.

Arf, c'est du GTK+ 2 => Epic Fail :/
Pour info GTK+ 3 est sortie debut 2011 soit il y a 3 ans maintenant…

Tout s'explique, GTK# est un binding pour GTK+ 2 uniquement, la version 3 n'est pas supportee : http://www.mono-project.com/GtkSharpPlan

Et ? Sur un Apple tu peux installer Linux, pourtant personne le fait.

C'est un mauvais exemple, quand Qt est sortie pour Symbian, Symbian etait deja a l'agonie (iOS et Android etaient deja la)…

Qt existe pour Windows CE depuis longtemps, difficile de juger de la popularite du truc, neanmoins "KDAB’s customers still showed a lot of interest in the platform we decided to step forward to fill the gap"

A mon avis Qt pour iOS et Android n'est pas inintéressant mais arrive un peu tard.

C'est du GTK# (i.e le binding GTK+ pour C#/Mono).

Le screenshot au dessus ne montre pas plein d'elements graphiques importants : scrollbars, buttons, combo-buttons, checkboxes, input… + les effets de focus-in focus-out.

Je l'ai installe sur mon Mac pour voir, et c'est jolie, il y a un veritable effort d'integration, c'est vraiment pas mal.
On repere quand meme que c'est pas du natif OS X (j'ai lancé le panneau de preferences - c'est la que l'on voit le plus les elements graphiques de base) : les tabs, les combobox et les couleurs ne sont pas identiques a OS X natif.

Pas contre la boite de dialogue pour ouvrir un fichier est natif OS X !

A lire : The Making of Xamarin Studio (2013/02).

Apparemment ils ont fait des #if OS_X #else dans le code de l'application en plus d'un theme GTK+ specifique pour que ca s'integre bien dans OS X.

MonoDevelop was originally developed entirely using the Gtk# APIs.

[...] We added platform-specific code in various places where the native platform would be exposed. For example, contextual menus are now drawn using the native theme, file dialogs are system dialogs, and the Gtk+ behavior and theme has been tuned to be closer to each platform’s guidelines.

[..] we created a new Gtk+ theme that builds on the native features and makes it ours (you can see our xamarin-gtk-theme on GitHub).

Ils n'ont malheureusement pas integre ca directement dans GTK+ alors que c'est de base avec Qt.

Arf, c'est du GTK+ 2 => Epic Fail :/
Pour info GTK+ 3 est sortie debut 2011 soit il y a 3 ans maintenant…

Et le dernier commit date d'il y a 7 mois…

Ils sont pas déjà tous partis sur mate, XFCE, voire Cinnamon ?

Ils sont partis sur Mac OS X, suffit de faire des confs pour le verifier (meme les confs Linux/KDE/GNOME).

La communauté aurait aussi pu développer un "OpenQt" avec une API compatible, le tout sous licence LGPL

C'est exactement ce qui c'est passé ! http://en.wikipedia.org/wiki/Harmony_(toolkit)
Ca n'a pas abouti puisque Qt est passé sous licence GPL en 2000.

Ils ont deja montre que Dart pouvait etre 2x plus rapide que JavaScript

Voici une presentation (2014/01/02) d'un ingenieur Google qui travaille sur V8 et la VM Dart et qui a auparavant travaille sur une VM Java.
(Pour info Lars Bak a aussi travaille sur une VM Java en plus de Smalltalk : HotSpot quand il etait chez Sun).

Il compare le fonctionnement de la VM V8 et de la VM de Dart : Building an Optimising Compiler for Dart

Je ne comprends pas comment tu peux faire autant de reproches a la demarche de Google et en meme temps etre fanboy de Microsoft/C#. Autant d'incoherences, pour moi ca releve de l'arnaque intellectuelle :/

J'ai pas tout compris a ton dernier commentaire. Je pense qu'il y a incomprehension mutuelle.

Les 3 personnes de base pour chaque comite/groupe de travail/peuimportelenom de l'Ecma ne presage pas du nombre de personnes qui vont y travailler (on ne connait pas ce nombre et vu le peu d'info que donne l'Ecma de maniere generale, peu de chances qu'on le connaisse un jour).

Faisons confiance a l'Ecma et Google, il y a peu de raisons que ca finisse en fiasco comme pour le format Open XML de Microsoft cf http://fr.wikipedia.org/wiki/Office_Open_XML#Un_projet_de_norme_contest.C3.A9

Oui mais non

Pour TOUS les groupes de travail il y a un president, un vice-president et un secretaire (ba ouai c'est logique hein). En conclure qu'il y a seulement 3 personnes dans le groupe de travail de Dart est faux.

Probable qu'il y ai déjà d'autres personnes d'inscrites […] Tout le reste n'est pas publique

Et donc tu ne peux pas tirer de conclusions.
Et oui on imagine bien que comme le groupe de travail vient d'etre cree, il y a probablement peu de personnes. Peut-etre qu'il y a meme reellement que 3 personnes.
Dans tous les cas ton raisonnement est simplement faux, point barre.

Admettre que t'as lu un peu trop vite la page de l'Ecma, ca va pas te trouer le cul hein…

J'ai pas inventé l'eau tiède

Le preuve que non :) (Ah oui quand j'ai demande la source, c'etait un piege hein…)

http://www.ecma-international.org/memento/TC39.htm (ECMAScript)

• Chairman => Mr. J. Neumann (Microsoft/Yahoo/Mozilla)
• Vice-Chairman => Vacant
• Secretary => Dr. Istvan Sebestyen (Ecma International)

http://www.ecma-international.org/memento/TC49.htm (C#)

• Chairman => Mrs. C. Eidt (Microsoft)
• Vice-Chairman => Vacant
• Secretary => Dr. Istvan Sebestyen (Ecma International)

Je pense qu'il n'y a pas besoin d'epiloguer sur le fait que t'as sorti une grosse connerie :)
Bien sur TImaniac c'est empresse de conclure que le groupe de travail pour Google n'est pas credible : 3 personnes dont 2 de chez Google.

actuellement il y a 3 personnes dont 2 de chez Google

Source ?

Non seulement il faut implémenter Dart dans les nouveaux navigateurs pour en tirer parti mais en plus toutes les étapes de manipulation DOM et events sont à réapprendre

Pour obtenir de meilleurs perfs que JavaScript, en effet il faut la Dart VM.
Mais la rupture que tu decris n'existe pas : dart2js permet de convertir du code Dart vers JavaScript (avec des perfs identiques a du JavaScript ecrit a la main).
Exactement de la meme facon que CoffeeScript ou TypeScript.

Quant a reapprendre les APIs (pas bien epaisses) pour manipuler le DOM et les events (click, focus, hover…), c'est simplifie dans Dart et les fonctions s'inspirent de celles de jQuery.

Exemple :

elem.querySelector('#foo');
elem.querySelectorAll('div');
elem.querySelectorAll('[name="foo"]');
elem.querySelectorAll('.foo');
elem.querySelector('.foo .bar');
elem.querySelectorAll('.foo .bar');

var subscription = elem.onClick.listen((event) => print('click!'));
subscription.cancel();

querySelector() va te retourner un seul element contrairement a jQuery qui retourne systematiquement une liste. De plus c'est "built-in" dans le langage, pas besoin de passer par une librairie externe.

Reellement, ca prends 30s chrono pour n'importe qui qui a deja ecrit du code jQuery et les avantages sont immediats.

pas d'exemple "real life"

Cf http://www.parleys.com/play/52a9897ce4b04354fb7e57d0/chapter19/about : Montage, Blossom.io - apparemment bien etabli, GreenTea/Angular.dart
Oui c'est vrai, c'est encore pauvre comme exemples et Dart doit encore convaincre.

Ta remarque "on sait ce qui se passe quand une techno google n'a pas le succès escompté" est parfaitement valide et tout le monde en a conscience. La normalisation du langage, l'integration de Dart VM dans Chrome et l'utilisation grandissante de Dart en interne par Google sont des elements determinants.

---

Revenons a ams.js.

1- Encore une fois, ca n'a pas le meme but. Les demos que tu donnes en exemples le montrent bien : ce sont des compilations de jeux videos OpenGL C/C++ !

Crois-tu que asm.js va remplacer du code JavaScript/jQuery (ou CoffeeScript, TypeScript…) avec AngularJS ou Backbone.js ?

Pourquoi alors Mozilla travaille encore sur les futurs versions de JavaScript si asm.js va tout changer ? Va t-on ecrire le prochain Facebook avec asm.js ?

2- asm.js n'est pas plus rapide que JavaScript au sens ou tu l'entends.
asm.js est plus rapide que JavaScript quand on compare l'execution d'un code C/C++ compilé vers JavaScript classique VS vers asm.js avec une VM specialisee. Il est aussi possible de comparer le code C/C++ original et la version compilee asm.js.
Mais il n'est pas possible de prendre une appli web existante (JavaScript, jQuery, Backbone.js), de la recompiler avec asm.js et de comparer les perfs : c'est juste completement different.

3- asm.js est une approche intelligente, comparativement peut-etre meilleur (ou pas) que NaCl (je n'ai utilise ni l'un ni l'autre).
Ca vient de sortir, ca a fait le buzz fin 2013, attendons que le buzz soit retombe.