Sommaire
- L’obsession du toolkit
- Comment les applications libres en souffrent
- Expérience personnelle à Mozilla
- Conclusions
Après une longue pause, voici un nouvel épisode (l’épisode précédent est ici) de cette série où j’essaye de pointer des motifs récurrents derrière les échecs de nombreux logiciels libres à destination du grand public.
Sujet du jour : l’obsession du toolkit. Tenez, ce mot‐là, je ne vais pas essayer de lui trouver un équivalent français, parce que rien que de réserver un bon mot pour ça, c’est déjà trop. Disons simplement que par toolkit j’entends une bibliothèque d’interface utilisateur, comme GTK+ ou Qt.
L’obsession du toolkit
Pourquoi parler d’« obsession » ? Ceci sous‐entend que les libristes ont tendance à accorder trop d’importance à ces toolkits, et que c’est une mauvaise chose.
Il n’y a pas besoin de rappeler que le monde du bureau libre est très focalisé sur le toolkit, avec l’éternelle division entre GTK+ et Qt. L’une des premières choses qu’on dit sur une application tournant sur un bureau libre, c’est quel toolkit elle utilise.
C’est intéressant : par contraste, sous Windows, on parle rarement de ça, alors qu’il existe encore plus de toolkits différents. Et sur le Web, on ne sait même pas combien de toolkits existent ; voici même une page qui en liste une quinzaine !
Un autre axe intéressant à étudier est celui de l’homogénéité des interfaces utilisateur des différentes applications. C’est considéré comme très important sur les bureaux libres, mais sous Windows et sur le Web on n’y pense même pas.
On me dira que je choisis mes exemples avec mauvaise foi : et Apple ? et Android ?
Je ne m’intéresse pas ici à l’exemple d’Apple pour deux raisons :
- malgré tous leurs succès, les plates‐formes Apple restent minoritaires, aussi bien sur le bureau (face à Windows) que sur mobile (face à Android). Or, ce qui m’intéresse ici, c’est de savoir comment les bureaux et applications libres pourraient devenir majoritaires sur le marché ;
- Apple fait de l’ergonomie un de ses principaux arguments de vente, ce qui conduit à gonfler l’importance du toolkit.
Je ne m’intéresse pas non plus ici aux plates‐formes mobiles (iOS et Android), parce que le mobile est encore un monde très jeune où les choses évoluent très vite, ce qui conduit naturellement à plus d’intégration et donc à adhérer à un toolkit unique. Je m’attends à ce que ça se relâche, dès que l’évolution du mobile se tassera.
Bref, ce qui m’intéresse, c’est comment faire une plate‐forme de bureau à succès. Et, si nous regardons les deux plates‐formes qui ont eu le plus de succès ces 15 dernières années, Windows et le Web, force est de constater que sur ces plates‐formes le toolkit n’est pas considéré comme un sujet très important.
Comment les applications libres en souffrent
Maintenant, je voudrais aussi vous convaincre que les bureaux et applications libres ont énormément souffert de leur obsession du toolkit.
Et ce, de plusieurs façons.
Le plus évident à critiquer ici est Qt. Ce toolkit a très tôt enflé pour devenir un cadre complet de développement d’applications, allant jusqu’à remplacer les classes‐conteneurs de la libstdc++. Et comme beaucoup de projets libres, Qt n’a pas compris non plus l’importance de préserver la compatibilité sur le long terme. Résultat, le passage de Qt 3 à Qt 4 a gravement endommagé le projet KDE. En 2006, KDE 3.5 était retenu par Asus pour être préinstallé sur les premiers Eee PC. En 2012, KDE n’est utilisé que par une petite minorité des utilisateurs de Linux de bureau, eux‐mêmes très minoritaires. On peut dire que KDE a manqué ses plus belles opportunités, à cause de sa dépendance excessive en son toolkit.
Du côté de GTK+, sans parler de GNOME ici, la transition à GTK+ 3 se passe mieux, simplement parce que GTK+ est beaucoup plus petit que Qt.
Un autre problème, causé par l’obsession du toolkit, est bien entendu de diviser en deux le marché. Cela conduit à des situations où, plutôt que d’utiliser la meilleure application pour une tâche donnée, on en crée une nouvelle qui utilise son toolkit préféré. Je n’ai pas besoin de donner d’exemples de ça, n’est‐ce pas ?
Allez, prenez Amarok 1.x vers 2006. Il était considéré par beaucoup comme le meilleur lecteur audio de tous les temps, toutes plates‐formes confondues. Mais, il a souffert des deux problèmes décrits ci‐dessus : des fans de l’Autre Toolkit ont préféré copier ses fonctionnalités dans d’autres logiciels plutôt que d’y contribuer, tandis que les propres développeurs d’Amarok ont préféré passer leur temps à le porter à Qt 4 et à toutes sortes de bibliothèques de KDE 4. Résultat, de ces deux manières différentes, l’obsession du toolkit est responsable de la stagnation d’Amarok en termes de fonctionnalités vraiment utiles sur 5 ans.
Enfin et surtout, l’obsession du toolkit décourage les éditeurs de logiciels indépendants de faire des portages pour nos bureaux libres. Ceci de plusieurs façons : en plaçant des attentes trop élevées en termes d’intégration (« si les combobox n’ont pas des coins arrondis, j’en veux pas »), en empêchant l’émergence de solutions simples qui marchent partout (aucun éditeur ne veut faire une version GTK et une version Qt), et en freinant l’amélioration de chaque plate‐forme, l’empêchant d’atteindre le point où elle aurait le niveau de qualité qui lui permettrait de conquérir de vraies parts de marché (plus que 1 %) et donc d’intéresser les développeurs d’applications indépendants.
Expérience personnelle à Mozilla
C’est bien connu, les applications de Mozilla s’intègrent assez peu dans les bureaux libres. On utilise certes GTK sous X11, et quelques services GNOME, mais on ne va pas assez loin pour offrir l’expérience utilisateur la meilleure possible.
Lorsque j’ai rejoint Mozilla, j’étais encore un développeur de KDE et j’ai essayé de parler à des gens pour voir quelles possibilités d’intégration dans KDE on pourrait envisager.
À chaque fois, le résultat est le même : on n’a déjà pas les ressources qu’on voudrait pour développer les fonctionnalités centrales d’un navigateur Web, et pour faire l’intégration aux plates‐formes les plus importantes sur le marché. Pourquoi dans ces conditions investir dans KDE qui ne doit pas représenter plus de 0,2 % du marché ?
À peu près à cette époque là, il est devenu assez clair qu’Ubuntu devenait archi‐dominant parmi les distributions Linux, suivi de Fedora (et leurs dérivées), et que les acrobaties boursières de l’ex‐Trolltech se finissaient de la façon la plus ridicule possible avec le noyautage de Nokia par un grand actionnaire de Microsoft. Il devenait évident que, si un toolkit de bureaux libres méritait notre attention, c’était bien GTK.
Mais à ce moment‐là, GTK commençait sa transition vers GTK 3, et ça allait à nouveau nous causer beaucoup de problèmes, parce que GTK 3 ne peut pas être utilisé conjointement avec GTK 2, ce qui rend toute tentative de portage vraiment difficile, en particulier avec les greffons binaires utilisant GTK 2.
On peut dire que le portage à GTK 3, particulièrement difficile pour un navigateur Web comme Firefox qui utilise des widgets GTK natifs (par contraste, Chromium dessine ses propres widgets), absorbe 100 % de l’énergie que Mozilla est capable d’investir dans du travail sur GTK, et en plus de ça, bloque la possibilité de faire participer le reste de la communauté à des efforts d’intégration dans des bureaux libres, car le portage à GTK 3 est un prérequis pour ça, et seuls quelques ingénieurs à Mozilla et à Red Hat ont la compétence requise pour y participer. Voir ce bogue
Ainsi, si GTK avait entièrement accepté l’idée qu’un toolkit, ça n’est qu’une bibliothèque comme une autre, et donc, qu’en cas de nouvelle version majeure, il faudrait permettre d’utiliser les deux conjointement, l’intégration de Firefox dans les bureaux libres serait probablement plus avancée aujourd’hui.
De plus, il est impossible pour moi, de mon point de vue Mozilla, de ne pas y voir une leçon ici : lorsque les développeurs d’un bureau libre déclarent que ceci ou cela est la bonne façon de développer une application pour leur bureau, cette information n’est fiable qu’à court terme et sa validité se repose sur l’idée, non réaliste, que les applications vont pouvoir se re‐porter à chaque version majeure suivante. Par exemple, lorsque Firefox est passé à des widgets GTK 2 natifs et à Cairo/XRender pour son rendu 2D, c’était considéré comme la bonne façon de faire, mais maintenant ça n’est qu’un handicap face à un concurrent, Chromium, qui ne s’est pas embêté avec ça (dessine ses propres widgets, a sa propre bibliothèque 2D, Skia, qui n’utilise pas d’API X11) et s’en porte mieux.
Conclusions
Répétez avec moi : « Un toolkit, ça n’est qu’une bête bibliothèque qui fait tourner une boucle d’événements et dessine des boutons. »
Ça n’aurait jamais dû devenir le handicap que c’est devenu pour les bureaux libres.
Si je lançais un projet de bureau libre aujourd’hui, et que ce bureau n’était pas un bureau Web, son principe de base serait de faciliter ou au moins de ne pas gêner le développement de grandes applications. Pour ça, il faut non pas insister sur un toolkit en particulier, mais au contraire accepter (comme Windows, et comme le Web) l’idée que chacun veut faire les choses à sa façon, et qu’on ne peut rien y changer. Un environnement de bureau libre doit certes implémenter quelques mécanismes d’inter-opération entre applications, mais ces mécanismes ne devraient pas forcer les applications à choisir un toolkit en particulier (et encore moins à se lier à une panoplie de bibliothèques de bureau). Il faut standardiser un faible nombre d’interfaces pour que les applications inter‐opèrent entre elles et avec le bureau, et ces interfaces devraient êtres les plus légères et non intrusives possibles en termes de l’architecture des applications.
# 2ème -> 3ème
Posté par Benoit Jacob (site web personnel) . Évalué à 1.
Zut, mon titre est faux, c'est la 3ème partie. Apparemment on ne peut pas éditer un journal déjà publié.
[^] # Re: 2ème -> 3ème
Posté par BAud (site web personnel) . Évalué à 2.
si, bien sûr. Ok, il faut être modo pour cela, mais c'est possible (et, en plus, il y a quelques coquilles et typos et syntaxe markdown qui peuvent être revues au passage).
[^] # Re: 2ème -> 3ème
Posté par ckyl . Évalué à 7.
Donc la réponse est "non, bien sur" ;)
[^] # Re: 2ème -> 3ème
Posté par BAud (site web personnel) . Évalué à 2.
bin si, quand "on" désigne les modos ; je n'ai pas rencontré de souci pour éditer un journal depuis longtemps (quoique, ponctuellement cet été, mais cela n'a pas duré).
Indirectement, tout le monde peut éditer un journal, une bonne pratique est d'attendre le 4ème ou 5ème fil de commentaire (plutôt que le premier) pour demander, cela évite de détourner la discussion du sujet. Ou, contacter les modos pour que cela soit fait, il y a un lien en bas à droite Team LinuxFr.org.
[^] # Re: 2ème -> 3ème
Posté par chamandier . Évalué à 2.
J'en profite pour m'exciter sur un point :
deuxième, s'abrège simplement avec un 'e'.
le XXe siècle / la 4e version du site.
C'est curieux mais parfois la simplicité ne l'emporte pas.
(J'ai même vu sur une pancarte : "la 4ième pizza offerte" )
Mais ne vous formalisez pas, cette erreur est courante, et mon commentaire n'infléchira rien au fait que vraiment ma bonne dame on va droit dans le mur à force de suivre cette pente glissante.
[^] # Re: 2ème -> 3ème
Posté par Nonolapéro . Évalué à 3.
Même mieux, un
2^edans la zone d'édition permet d'obtenir un 2e de même pour 1er ou 1re .[^] # Re: 2ème -> 3ème
Posté par chamandier . Évalué à 0.
ici, par "même mieux", j'entends, "comme je vais te casser".
Mais avec la casse, on reste dans la typo.
# Une solution ?
Posté par LaBienPensanceMaTuer . Évalué à 8.
Je ne suis vraiment pas sûr que un environnement de bureau décousu soit une bonne idée pour faire adopter plus massivement GNNU/Linux sur les desktop.
Tu n'as qu'à voir, un utilisateur lambda va déjà râler quand tu le fais passer de Office à Open Office (alors que le délai de ré-acclimatation est de l'ordre d'une semaine), alors imagine si tu le fais passer à un environnement ou, parfois la décoration de la fenêtre est noire, d'autre blanche. Ou les boutons de fermeture sont à gauche dans la majorité des cas, et à droite parfois.
Non, je pense (mais ce n'est que mon avis) qu'il est important de conserver des interfaces cohérentes en terme de look'n feel.
Par contre, la solution ne serait elle pas d'implémenter une couche supplémentaire ?
Par là, j'entend une lib au dessus de GTK/QT/Xlib/Whatever qui proposerait une API d'abstraction à ces toolkit dont tu parles.
Le développeur libre n'aurait qu'à utiliser cette librairie, et cette dernière se chargerait, en fonction du contexte d'exécution, d'appeler le toolkit le plus adapté.
Je suis conscient qu'un tel développement n'est pas particulièrement attrayant pour le geek passionné (et c'est peut être pour cette raison que je ne suis pas parvenu à trouver une telle lib), mais cela résoudrait l'air de rien énormément de problème :)
Après, je ne connais pas assez les différents toolkit pour avoir la certitude qu'une telle abstraction serait faisable facilement.
[^] # Re: Une solution ?
Posté par qdm . Évalué à 7.
Un PulseAudio du graphisme, donc ? Super…
[^] # Re: Une solution ?
Posté par LaBienPensanceMaTuer . Évalué à 10.
C'est pas parce qu'un concept a été mal appliqué une fois qu'il le sera à jamais :)
Regarde le communisme. Euh … non rien en fait.
[^] # Re: Une solution ?
Posté par liberforce (site web personnel) . Évalué à 8.
Pas vraiment, je dirais plutôt un Phonon (KDE) du graphisme.
[^] # Re: Une solution ?
Posté par EdB . Évalué à 8.
http://www.wxwidgets.org/ ?
[^] # Re: Une solution ?
Posté par LaBienPensanceMaTuer . Évalué à 4.
hmmm … je ne m'étais jamais trop intéressé à wxwidgets et je croyais que cette lib implémentait son propre look & feel …
Je vais regarder d'un peu plus près, mais quelqu'un pourrait me confirmer qu'un même binaire (par exemple, je vois qu'Audacity figure dans la liste des applis utilisant cette lib) aura un rendu en QT si lancé sous KDE et un rendu en GTK si lancé sous Gnome ?
[^] # Re: Une solution ?
Posté par EdB . Évalué à 3.
Elle implémente le look and feel de l'environnement sous jacent. Par contre il semble que sous linux, ce soit GTK.
[^] # Re: Une solution ?
Posté par coid . Évalué à -6.
J’ai utilisé WxWidgets sur Windows, j’en étais content.
Puis j’ai vu qu’elle utilisait une surcouche GTK sur Linux. Je l’ai donc abandonnée, car je déteste GTK et j’évite toutes les applications qui utilisent ce toolkit.
[^] # Re: Une solution ?
Posté par Troy McClure (site web personnel) . Évalué à 6.
Dommage , car il y a certes wxgtk, mais il y a aussi wxx11 qui tape directement sur la xlib
[^] # Re: Une solution ?
Posté par liberforce (site web personnel) . Évalué à 10.
Pour avoir utilisé wxWidgets, je peux t'assurer que ce n'est pas la solution. En gros c'est une surcouche au dessus du toolkit principal de l'OS utilisé (pour Linux, c'est GTK qui a été choisi). Tu te retrouves dans l'API avec des fonctions où on te dit "celle ci ne marche que sous Windows, celle là que sous Linux", etc. Donc c'est pas transparent du tout, et tu finis par pondre du code non portable si tu ne fais pas attention, et en plus tu te chopes une surcouche de bugs par dessus ceux du toolkit que tu abstraits.
[^] # Re: Une solution ?
Posté par EdB . Évalué à 6.
Attention, je n'ai jamais dit que c'était la bibliothèque à utiliser (j'ai même un avis négatif).
C'est juste que je présentait une réponse a l'affirmation que personne n'avais développer une abstraction au dessus des toolkits.
[^] # Re: Une solution ?
Posté par liberforce (site web personnel) . Évalué à 3.
C'est pour ça que je t'ai pertinenté alors que tu étais en négatif ;-)
[^] # Re: Une solution ?
Posté par Nitchevo (site web personnel) . Évalué à 7.
En fait je suis assez d'accord avec l'auteur de ce journal, les toolkits ont fait beaucoup de mal et continuent encore aujourd'hui.
Mais reste la dernière question: faut-il conserver Qt ou Gtk+?
[^] # Re: Une solution ?
Posté par zebra3 . Évalué à 3.
Moi aussi. Il est clair que Windows avec sa multitude de toolkit est horriblement moche. Même Microsoft n'est pas foutu de se mettre d'accord avec lui-même, il n'y a qu'à voir Office qui n'utilise pas Metro.
A contrario, GNOME et KDE, en n'employant chacun qu'un seul toolkit, permettent de fournir l'expérience utilisateur la plus clair et cohérente possible. Tout comme Apple d'ailleurs.
Au passage :
Pourtant, les développeurs d'Epiphany s'en sont sortis alors qu'ils utilisent les widgets natifs, et ils ont moins de ressources que Mozilla (ils ne reçoivent pas de sous de Google).
C'est que ça ne doit pas être si compliqué. Mais si ça l'est vraiment, peut-être faut-il remettre en doute l'architecture du navigateur plutôt que le toolkit…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Une solution ?
Posté par Benoit Jacob (site web personnel) . Évalué à 4.
Epiphany est un navigateur a minima au-dessus de WebKit, donc l'effort de portage est incomparablement plus faible que pour Firefox. Il y a aussi des facteurs architecturaux, mais ça n'est pas une raison de critiquer les choix architecturaux de Firefox, au vu des bénéfices qu'il en tire par ailleurs (Firefox étant plus multi-plateformes et faisant de l'intégration dans des plate-formes non-GTK, et offrant à ses add-ons des capacités d'intégration impossibles à offrir avec WebKit).
[^] # Re: Une solution ?
Posté par Patrick Nicolas . Évalué à 4.
Justement, l'architecture de Chrome/Epiphany/Safari/Midori/plein d'autres est d'utiliser une librairie pour le rendu html, qui n'est qu'une partie du navigateur, une pour l'affichage, une pour le moteur javascript etc.
Je ne demande pas à ce que tout le monde utilise un bureau Linux, juste que ce bureau corresponde à ce que je veux et qu'on ne m'empêche pas de l'utiliser. Les toolkits sont une véritable force et j'aime beaucoup la cohérence qu'ils apportent.
[^] # Re: Une solution ?
Posté par Benoit Jacob (site web personnel) . Évalué à 4.
Il y a deux catégories de navigateurs "WebKit".
La catégorie des navigateurs WebKits qui prennent au sérieux cette histoire de bibliothèques bien séparées; cette catégorie comprend uniquement des "petits" navigateurs comme Epiphany que presque personne n'utilise, qui ont généralement de 1 à 3 ans de retard sur les fonctonnalités Web des principaux navigateurs, et qui n'offrent pas beaucoup des fonctionnalités d'un navigateur moderne qui ne sont pas fournies par ces bibliothèques (par exemple Sync).
Et puis les navigateurs qui se moquent comme d'une guigne de cette histoire de bibliothèques séparées, qui ont leur propre variante de WebKit, qui le développent conjointement à leur propre moteur JS, et leur propre code applicatif. Cette catégorie inclut tous les navigateurs WebKit qui ont jamais rencontré le succès, en particulier Chrome et Safari.
Bref, l'histoire des jolies bibliothèques bien propres et séparées, c'est une énorme arnaque et ceux qui y croient le font à leurs dépens. En fait, c'est exactement la même histoire qu'avec les toolkits.
[^] # Re: Une solution ?
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Il y a deux catégories de navigateurs "WebKit".
Il y a les navigateurs poussés par des équipes qui ont peu de moyens (Gnome), qui ont généralement de 1 à 3 ans de retard sur les fonctonnalités Web des principaux navigateurs, et qui n'offrent pas beaucoup des fonctionnalités d'un navigateur moderne qui ne sont pas fournies par ces bibliothèque, et donc prennent au sérieux cette histoire de bibliothèques bien séparées parce qu'ils n'ont pas de temps à passer à réinventer la roue et réintégrer ce qu'ils ont désintégré, pour pouvoir se concentrer sur les fonctionnalités qu'on attend depuis 3 ans.
Il y a les navigateurs poussés par des équipes qui ont plus de moyens (Google, Apple), qui ont leur propre variante de WebKit, qui le développent conjointement à leur propre moteur JS, et leur propre code applicatif, parce qu'ils ont les moyens de pouvoir se moquer comme d'une guigne de cette histoire de bibliothèques séparées.
Je crois que tu vas un peu vite pour désigner les causes et les conséquences. Ton exemple tire des conclusions sur des corrélations alors que ces corrélations ne suffisent en rien.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Une solution ?
Posté par Benoit Jacob (site web personnel) . Évalué à 4.
La contradiction peut se résoudre en admettant qu'il est impossible de maintenir un navigateur Web compétitif sans une équipe d'au moins, disons, 50 personnes (et c'est très optimiste) même en ayant une assez grande partie du travail fourni par WebKit.
[^] # Re: Une solution ?
Posté par Thomas Debesse (site web personnel) . Évalué à 1.
Donc tu reconnais que si le problème des petits navigateurs est de ne pas avoir une équipe de 50 personnes derrière, en fait, les différences stratégiques que tu évoques (maintenir une espèce de fork ou bien être le plus vanilla possible) ne sont finalement que problème secondaire et conséquence ? Comment alors baser un argumentaire présentant ces conséquences commes causes premières ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Une solution ?
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
J'ai dit qu'avoir une équipe d'au moins 50 personnes était une condition nécessaire; je n'ai pas dit que c'était une condition suffisante.
[^] # Re: Une solution ?
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à -6.
Ah Chrome ne serait donc pas le navigateur le plus utilisé au monde ? Genre bien plus utilisé que Firefox ? Et Safari ne serait pas le navigateur utilisé par une personne sur 10 ?
Sérieusement faudrait sortir de sa caverne des fois…
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Une solution ?
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
Ton commentaire montre que tu n'as pas lu le mien.
[^] # Re: Une solution ?
Posté par pikapika . Évalué à 9.
c'est simple : EFL
[^] # Re: Une solution ?
Posté par Zenitram (site web personnel) . Évalué à 8.
Qt essaye de ressembler à GTK sous Gnome, c'est déjà un pas. Ca reste le toolkit le plus "indépendant" (= qui s’adapte à l'utilisateur, et non l'inverse).
Reste qu'au final, mon expérience avec les toolkit me font pour le moment conclure que pas le choix, on doit développer par toolkit natif si on veut être cohérent, malheureusement… Ou alors, se foutre de l'intégration (ça marche aussi pas mal).
[^] # Re: Une solution ?
Posté par Stéphane Klein (site web personnel) . Évalué à 6.
Non en dessous… une lib qui s'occupe d'afficher le rendu d'un bouton en fonction de son état… rien de plus… une sorte de thème CSS avancé… qui serait utilisé par Gtk, Qt… comme ça le look serait identique d'un toolkit à l'autre.
Mais j'avais cru voir… qu'on allait vers cette direction…
[^] # Re: Une solution ?
Posté par LaBienPensanceMaTuer . Évalué à 3.
Bein au dessus ça me semblait cohérent. Pourquoi ? C'est simple, le jour ou Jay sort une release de MultiDeskos, il suffit de rajouter le support de JayTK (palapapa pala) à notre super lib pour que toutes les applications soient d'un seul coup d'un seul compatible et intégrée visuellement à Multideskos.
[^] # Re: Une solution ?
Posté par EdB . Évalué à 4.
Comme Qt donc, qui s'adapte au style de l'environnement cible
[^] # Re: Une solution ?
Posté par Obsidian . Évalué à 10.
C'est une idée récurrente depuis l'aube de l'informatique et résumée par ceci :
Moi, j'appelle ça la théorie de la décharge à ordures : à l'instar de ces dépôts où l'on entasse toutes les ordures du département, avant de les recouvrir par une couche de terre pour en re-déverser encore dessus par la suite, on assiste régulièrement à l'établissement d'une nouvelle couche d'abstraction unifiée censée guérir tous les maux de la Terre et blanchir les dents pendant le sommeil. C'est oublier le fait qu'une fois qu'elles sont en place, et sous réserve qu'elles soient à la fois réussies, adaptées aux besoins des développeurs comme des utilisateurs et qu'elle aient gagné leur bataille contre les autres technologies similaires, le moment où elles commencent réellement à jouer leur rôle (quand les développeurs se l'approprient et s'appuient dessus) coïncide en général avec celui où l'on voit apparaître — au dessus de cette couche — de nouvelles technologies concurrentes. Le problème réapparaît alors comme la mauvaise herbe jusqu'à ce que, tôt ou tard, on soit contraint de mettre par dessus ce fatras une nouvelle couche d'abstraction.
La seule vraie solution consiste à pondre quelque chose qui soit vraiment meilleure sur tous les plans, c'est-à-dire innovante, capable de s'adapter sur une longue durée à l'évolution (donc faire de la futurologie, et en informatique de surcroît), beaucoup plus simple que tout ce qui existait jusqu'alors, sans régression et si possible compatible, binairement et dans la philosophie pour que les gens qui ont beaucoup investi de leur personne dans une technologie n'ait pas à tout reprendre de zéro. La quadrature du cercle, donc.
Sinon, il y a le rapport de force : verrouiller la technologie et se limiter à quelques use cases pour forcer les gens à s'y conformer. Ça a l'air de bien marcher avec Apple, mais dans le logiciel libre c'est en général voué à l'échec (et on a beau être vendredi, je ne ferai pas état d'un certain projet d'environnement de bureau qui semble avoir pris le premier comme modèle).
[^] # Re: Une solution ?
Posté par chamandier . Évalué à -5.
Je suis assez nul en anglais, mais il me semble que la petite illustration ne comporte pas
ni jeu de mots intraduisible ni locution subtile propre à cette langue.
Bref, ça rime à quoi ?
Merci.
[^] # Re: Une solution ?
Posté par Obsidian . Évalué à 3.
Comment prolifèrent les standards (chargeurs de batteries, codage des caractères, messageries instantanées, etc.)
[^] # Re: Une solution ?
Posté par chamandier . Évalué à 0.
Merci de la traduction.
[^] # Re: Une solution ?
Posté par Michaël (site web personnel) . Évalué à 10.
C'est exactement le cas de Windows pourtant, où de nombreux programmes utilisent des thèmes qui ne font pas très natif. (VLC, Gimp, Safari, iTunes, les logiciel de montage vidéo Adobe, WinAmp, la plupart des programmes livrés avec une carte-mère ou autre… etc.)
Faut arrêter de prendre les gens pour des cons, ce qui freinent l'adoption de GNU/Linux pour le desktop est tout simplement que les gens n'en ressentent pas le besoin et qu'il ont déjà autre chose (vente forcée et tolérance du piratage). Pas la peine d'aller chercher plus loin. Pour accélerer l'adoption de GNU/Linux sur le Desktop il suffirait peut-être de dénoncer tous les gens qui utilisent des produits Microsoft piratés!
[^] # Re: Une solution ?
Posté par Obsidian . Évalué à 10.
Je pertinente fortement, mais j'ajoute également que je préfère que ces dernières personnes restent sous Windows et que l'on garde un système propre à côté.
[^] # Re: Une solution ?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 3.
Ce qu'il y a de bien avec les couches supplémentaires servant à abstraire des composants, c'est qu'il en a plusieurs parmi lesquelles peux choisir. Insert
<xkcd>here…[^] # Re: Une solution ?
Posté par cedric . Évalué à -1.
Developper ce genre de bibliotheque peut se resumer a dire que tu prends le plus petit commun denominateur et que tu vas avoir tous les inconvenients de tous les toolkits sans aucun avantage. De toute facon, tu ne pourras pas integrer des applications plus que visuellement (partager des informations, des liens, …). Et puis, je ne peux pas m'empecher de mettre un lien vers : http://xkcd.com/927/ .
# qt
Posté par EdB . Évalué à 10.
Ce journal semble ignoré que Qt un thème permettant d'avoir un look a ma GTK, et pas seulement coté graphisme, puisque ce mode reprend la façon particuliaire (et contre intuitive :o) ) de positionner les boutons.
Du coup Qt permet de ne pas ce focaliser sur le toolkit, vus que ce seras partout presque pareil.
[^] # Re: qt
Posté par LaBienPensanceMaTuer . Évalué à -2.
Mais si ton GTK est lui même "thémé" pour ressembler à autre chose que le look par défaut …. ça ne marche pu ?
[^] # Re: qt
Posté par Nitchevo (site web personnel) . Évalué à 10.
Nous nous sommes tant "thémé" que nous avons fini par nous ressembler
[^] # Re: qt
Posté par EdB . Évalué à 5.
J'avoue ne pas avoir regardé en détail, mais il me semble que ce sont les thème GTK qui sont lus et interprétés, que ce n'est pas un thème GTK hardcodé.
Mais je ne me suis pas intéressé au détail, n'ayant pas d'appli cross desktop ici.
[^] # Re: qt
Posté par Gof (site web personnel) . Évalué à 8.
C'est bien ça.
Le thème GTK utilise GTK lui même pour le rendu.
Et quand on change de thème GTK, les applications Qt changent en même temps.
[^] # Re: qt
Posté par flan (site web personnel) . Évalué à 2.
Sauf que reprendre le look & feel natif, ce n'est pas seulement changer la couleur des boutons. Par exemple, tu peux avoir un widget (composant élémentaire de l'interface graphique : bouton, liste déroulante, élément de menu, …) qui existe sur un OS et pas sur un autre, comme c'est le cas avec Vista par rapport aux autres OS. Autre exemple, avec OS X, tu as une seule icône pour toutes les fenêtres de l'application, icône que tu peux animer (faire rebondir, ou la modifier).
C'est assez loin du modèle Windows XP et Gnome 2 où tu as une icône par fenêtre, icône qui est figée. Dur d'avoir un toolkit qui adopte vraiment le style natif de chaque plate-forme.
[^] # Re: qt
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
Mais également que QT est multiplateforme. Firefox n'aurait-il pas supporté Mac OS X beaucoup plus vite s'il avait utilisé QT ?
[^] # Re: qt
Posté par flan (site web personnel) . Évalué à 7.
Supporter OS X, ok, mais comment ?
Avoir une « vraie » appli OS X, c'est avoir une appli qui utilise les composants du système, du genre :
- le proxy
- le correcteur orthographique et grammatical
- les raccourcis clavier (modifiables par le système)
- le trousseau de mots de passe et de certificats
- les API pour les contacts et les mails
- l'API système pour faire du plein écran
Alors, oui, ça commence à arriver, mais que ce soit avec Qt ou avec un autre toolkit, il est nécessaire d'avoir du code spécifique à OS X (comme il en faut sûrement pour Linux ou Windows). Faire du code identique quelque soit l'OS et être bien intégré au système me semble vraiment impossible, quelque soit le toolkit utilisé.
[^] # Re: qt
Posté par Michaël (site web personnel) . Évalué à 4.
Quelque part, ça tombe sous le sens non? Si on veut tenir compte des particularités des systèmes il va bien falloir écrire du code pour cela.
[^] # Re: qt
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
Comme vlc par exemple. Qui est loin me semble-t-il d'être une application marginale sous Mac OS
[^] # Re: qt
Posté par fredoche . Évalué à 1.
Pas marginale, mais pas intégrée aux fonctions avancées de l'os non plus. On parle d'un truc qui va au dela de l'apparence, dans la mesure ou pour t'adapter à un OS tu /dois/ écrire du code spécifique.
# Et les autres?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Tk? Xul? Fltk? Swing?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et les autres?
Posté par Michaël (site web personnel) . Évalué à 8.
Et les widgets Athena! et XMotif?
[^] # Re: Et les autres?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2.
En ce moment, je suis en train (d'essayer) d'écrire une application X11 de base, en parlant directement à la
Xlib. C'est vraiment pas simple, mais c'est très didactique (rires). Et pour la prochaine, je pensais effectivement essayerxaw3d(je suis un fan inconditionnel de Xpaint (rires)). Hélas, il me semble avoir lu récemment dans les intertubes que ce dinosaure était plus ou moins à l'abandon…Si un vétéran du X11 a des informations sur l'état du projet, je suis preneur.
[^] # Re: Et les autres?
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Pourquoi pas xcb?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et les autres?
Posté par Batchyx . Évalué à 3.
J'ai déjà essayé d'utiliser xcb, mais c'est difficile de trouver de la doc pour. Pour faire ce que je voulais, j'étais obligé de lire la doc de Xlib, regarder son code source et le code source généré d'xcb pour savoir quel était la fonction équivalente. Xlib cache pas mal l'incongruité du protocole X11, alors que xcb est plutôt un binding 1:1 vers X11.
Mais bon, moi mon but n'était pas d'afficher une fenêtre.
[^] # Re: Et les autres?
Posté par Michaël (site web personnel) . Évalué à 3.
J'avais programmé en X grâce au livre d'Oliver Jones (je crois)… c'est effectivemement assez amusant et de toutes façons plutôt intéressant. (À défaut d'être profondément utile… :) )
[^] # Re: Et les autres?
Posté par BAud (site web personnel) . Évalué à 2.
xaw !
# Lapin compris
Posté par ParaDoxe . Évalué à 3.
œufs, lapin compris:
Tu peux avoir GTK2 et GTK3 installé sur le même système. Tu peux même avoir des thèmes très identiques. Dans Gnome, à partir de la version 3.6, le thème officiel est quasiment identique en GTK2 et GTK3.
[^] # Re: Lapin compris
Posté par zebra3 . Évalué à 2.
Je crois qu'il parlait d'utiliser les deux versions dans la même application. Mais je ne suis pas sûr que ça soit faisable avec d'autres tookits.
Et il était temps ! Le minimum eut été de proposer ça dès le début !
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Lapin compris
Posté par ParaDoxe . Évalué à 4.
Ça demande du boulot et il y a d'autres priorités.
Mais ça fais plaisir de voir une homogénéité dans les interface. J'ai plus l'impression que Liferea, Geany ou Firefox sortent d'outre tombe.
[^] # Re: Lapin compris
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
On vit dans le même monde ? J'ai utilisé Gnome Shell très tôt, je n'ai jamais eu de problèmes entres les applis GTK3 et GTK2 ! Je veux bien admettre que les applis GTK2 avaient parfois de petites variantes minimes (comme des petits détails sur la façon d'afficher un ascenseur par exemple), mais globalement j'ai toujours eu un affichage propre !
J'avais été très surpris de lire dans la dépêche sur Gnome 3.6 que la cohérence entre GTK2 et GTK3 avait été beaucoup améliorée, je me demandais ce que signifiait « beaucoup ». Je suis encore plus surpris quand je lis vos commentaires… Non vraiment j'aurai pu ne pas remarquer la différence entre GTK2 et GTK3… Et si j'ai pu voir d'infimes variations c'est sans commune mesure avec la différence Qt3/Qt4. Sur mon ordi, le seul moyen de ne pas avoir de cohérence entre GTK2 et GTK3 était d'utiliser un thème GTK2 only (et donc forcément, les applis GTK3 étaient moches car non thémées), mais j'ai toujours vu les thèmes GTK3 thémer convenablement et de manière très satisfaisante les applis GTK2.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Lapin compris
Posté par Lizzie Crowdagger (site web personnel) . Évalué à 1.
«Je crois qu'il parlait d'utiliser les deux versions dans la même application. Mais je ne suis pas sûr que ça soit faisable avec d'autres tookits.»
Même avec d'autres bibliothèques, c'est un truc qui se fait vraiment, de pouvoir utiliser deux versions différentes dans la même appli ? J'ai l'impression qu'avec la plupart des bibliothèques tu vas utiliser les mêmes symboles pour appeler les mêmes fonctions dans deux versions différentes et que c'est au moment du linkage que tu vas choisir la version, mais si t'as qu'un seul binaire je vois pas trop dire qu'à un moment le symbole plop_coin () doit être cherché dans libcoincoin.so.4 et que deux lignes plus loin il faut le chercher dans libcoincoin.so.5 ?
[^] # Re: Lapin compris
Posté par Misc (site web personnel) . Évalué à 3.
la façon de faire, c'est de prefixer l'api avec la version, mais du coup, tu pétes l'API à chaque fois :)
( mais sinon oui, comme charger php4 et php5, ou avoir mod_perl linké avec l'ancienne libpng et mod_python avec le nouveau, avoir des plugins en gtk3 et d'autres en gtk2 )
[^] # Re: Lapin compris
Posté par Gof (site web personnel) . Évalué à 2.
Et en C++ il y a des namespaces.
[^] # Re: Lapin compris
Posté par Croconux . Évalué à 4.
Je n'ai pas refait tourner un Gnome depuis un moment mais au moment du passage à Gnome 3, la différence entre les applis GTK2 et GTK3 était plus que visible.
Le thème par défaut de GTK2 n'avait pas été porté vers GTK3 (ça n'intéressait pas les développeurs à ce que j'avais lu) et le nouveau thème par défaut (les thèmes GTK3 se comptaient sur les doigts d'une main d'un habitant de Tchernobyl) n'existait pas pour GTK2. En un mot c'était la merde intégrale.
# Problème de fond
Posté par stopspam . Évalué à 7. Dernière modification le 12 octobre 2012 à 18:08.
Une obsession, je ne sais pas. Un base fondamentale, sûrement !
Comment mesures-tu le "trop d'importance" ? Dans tout ton texte, tu ne pointes pas l'origine du problème ou plutôt le besoin des développeurs car il y en a un : ça doit marcher sur le maximum de plateforme sans perdre de temps à réinventer la roue.
Ça veut dire utiliser l'existant (framework, toolkit) ou forker (ce qui explique le tas de projets qui existent sur ce segment). Ensuite baser son développement dessus.
Que ça soit sur jquery pour du web ou gtk pour du lourd je vais forcément être très vigilant sur les bugs (qui peuvent exploser mes projets) et les évolutions (est-ce que ça va toujours correspondre à mon besoin).
# Tu critiques Qt ?
Posté par Gof (site web personnel) . Évalué à 10.
Je vais un peu défendre Qt, parce que il me semble que tu confonds tout:
Bah oui, et c'est un avantage. C'est ce que Qt est, une biblitohèque unifiée pour faire des application (GUI mais pas seulement) en C++ et cross platforme.
Et d'ailleur, GTK+ fait juste partie d'un groupe de bibliothèques qui fait exactement pareil (et ça commence avec glib).
À l'époque, ils avaient leurs raison. Il se voulaient crossplatforme alors que la libstdc++ n'était pas complète. Rapellons que Qt existe depuis 1991, C'était longtemps avant la norme C++98.
Ensuite les conteneurs de Qt ont leurs propre raison d'être, mais je ne rentre pas dans les détails ici.
Ok, Qt4 a cassé la compatibilité avec Qt3. Mais c'était il y a 7 ans.
Qt5 est quasiment source compatible avec Qt4.
Et c'est pour le mieux. L'API de Qt4 est un énorme progrès par rapport avec son petit frère Qt3.
Tu mélange tout. KDE était plus que un simple portage à Qt4. Beaucoup de chose ont été réécrite aussi juste parce que ils en avaient l'occasion. Plasma, Akonadi, Nepomuk, Decibel et j'en passe.
C'est je pense ça qui a causé des problème à KDE. Car les projets qui se sont contanté d'être porté tout bêtement de Qt3 à Qt4 n'ont pas eu ce genre de problèmes.
C'est comme si je disait que les gens n'aiment pas le nouveau Gnome Shell à cause de GTK3
Non, ils ont aussi passé beaucoup de temps à repenser completement l'interface.
Porter à Qt4 n'est pas si compliqué. C'est ce qu'a fait Celementine, le fork d'amarok basé sur Amarok 1.4.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . Évalué à -1. Dernière modification le 12 octobre 2012 à 19:02.
On est bien d'accord sur les faits, mais on en tire des conclusions entièrement différentes.
Le meilleur exemple en est quand tu dis:
Donc voilà, du point de vue des développeurs de toolkits, pour sortir une nouvelle version du toolkit sans causer trop de problèmes, il suffit d'être "quasiment source compatible".
C'est là que je ne suis pas du tout d'accord: pour moi, la barre en termes de compatibilité est bien plus haut. Il faut aussi préserver à 100.00% la compatibilité binaire descendante: les binaires compilés pour Qt4 doivent continuer de s'exécuter sans aucune modification sous Qt 5, Qt 6, et ainsi de suite jusqu'à ce que vraiment presque plus personne n'ait de binaires Qt4 à faire tourner. Et, chose très importante, il doit rester possible d'utiliser les différentes versions simultanément, dans la même application.
Il y a différentes façon d'atteindre cet objectif. La façon Microsoft, qui est la première direction où regarder puisque c'est ce qu'il y a de plus proche techniquement et qu'ils ont un certain succès commercial, c'est simplement de continuer de distribuer des binaires des anciennes versions de leurs SDK, et de concevoir leurs interfaces pour permettre d'utiliser de multiples versions simultanément. C'est comme si les distributions binaires de Qt5 contenaient une copie des binaires de Qt4.
Android et Apple aussi continuent de distribuer leurs vieux SDK binaires avec les nouveaux.
Idem pour les distributions binaires d'implémentations d'OpenGL, qui sont les championnes de la compatibilité descendante, une application OpenGL 1.0 d'il y a presque vingt ans pouvant encore tourner sans recompilation sur n'importe quelle machine ayant des pilotes OpenGL.
Si les toolkits libres veulent être pris au sérieux, il faut qu'ils fassent la même chose. Dans mon journal, j'ai donné un exemple concret montrant en quoi le fait que GTK3 ne fait pas ça, est une grande cause de problèmes pour Firefox.
Du coup, le coût réel d'accroître un toolkit pour y include des choses come QVector et QList, est plus important dans ma vision des choses que dans la tienne, car ce gonflement va être multiplié par un certain facteur pour garantir la compatibilité au fil des années.
Je ne rentre pas plus dans le détail de ta réponse parce que je pense que le point important de désaccord était celui-ci.
[^] # Re: Tu critiques Qt ?
Posté par rewind (Mastodon) . Évalué à 9.
Et on peut faire tourner des applis codés pour Gecko 1.7 avec Gecko 14.0 ?
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . Évalué à 3.
Les applications utilisant Gecko distribuent leur propre copie de Gecko (par exemple, Firefox et Thunderbird ont leur propre copie) donc c'est un non-problème. On peut bien sûr pointer des inconvénients de cette approche (utilisation de quelques dizaines de MB de mémoire de plus) mais ces arguments ont à leur tour des contre-arguments (permettre à Thunderbird de distribuer un plus petit Gecko que Firefox, par exemple sans support de WebGL sous Windows qui est assez volumineux, etc).
[^] # Re: Tu critiques Qt ?
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Pourquoi n'y aurait-il aucune appli gecko qui ne distribueraient pas leur propre copie de Gecko ?
Qu'est ce qui empêche Gecko d'être distribué de manière à ce que l'on n'aie pas à distribuer sa propre copie ?
Pourquoi faut-il que Microsoft fournisse de quoi faire des interfaces comme à l'époque des win 16bit, pourquoi faudrait-il que GTK et Qt imitent cette stratégie, et pourquoi Mozilla serait par contre complètement exempté de devoir répondre à cette légitime attente, sous prétexte que certains ne le demandent pas ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . Évalué à 1. Dernière modification le 12 octobre 2012 à 22:36.
Gecko ne prétend pas être un toolkit, ni même en aucune façon utilisable comme une bibliothèque externe. On ne prétend pas ça. On ne peut pas empêcher des gens de le faire, mais ça n'est vraiment pas encouragé. Il y a très longtemps, on l'encourageait, mais cette époque est révolue depuis longtemps. Et je ne connais aucun project qui le fasse aujourd'hui.
A partir de là, il n'y a aucune validité à retourner contre Gecko les critiques que je formule contre des toolkits.
C'est comme si je disais "Peugeot n'investit pas assez dans les voitures hybrides" et que tu me répondais "Mozilla non plus".
[^] # Re: Tu critiques Qt ?
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
OK, si tu veux jouer…
Pourquoi faut-il que Microsoft fournisse de quoi faire des interfaces comme à l'époque des win 16bit, pourquoi faudrait-il que GTK et Qt imitent cette stratégie, et pourquoi Mozilla serait par contre complètement exempté de devoir répondre à la légitime attente de ceux qui font des interfaces avec XUL, sous prétexte que certains ne le demandent pas ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . Évalué à 1.
Parce que dans le monde réel, les gens ne considèrent pas acceptable que leurs applications binaires cessent de fonctionner quand ils mettent à jour leur système d'exploitation.
Il ne le faut que dans la mesure où les bureaux à base de GTK et Qt ambitionnent d'obtenir plus de 1% de parts de marché. On se souvient de GNOME qui ambitionnait 10% pour 2010.
Là on commence à tout mélanger: avant on parlait de Gecko comme bibliothèque binaire, maintenant tu parles de XUL. Si tu veux parler de ça il va te falloir un autre interlocuteur que moi, car je ne travaille personnellement que sur Gecko.
[^] # Re: Tu critiques Qt ?
Posté par Misc (site web personnel) . Évalué à 9.
Comme les extensions quand on mets à jour son navigateur, faudrait pas que ça casse ?
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . Évalué à 0.
Les extensions Firefox, ça n'est pas une partie intégrante du Web (puisque ça ne marche que dans Firefox).
Et d'autre part, la surface exposée par Gecko aux extensions (par XPCOM) est si énorme que c'est inévitable. Si tu veux des addons avec compatibilité à plus long terme comme dans certains autres navigateurs, la contrepartie inévitable est des add-ons moins puissants, comme dans ces autres navigateurs. Du point de vue du dév d'extensions, ça se discute, par contre, du point de vue de l'utilisateurs, après une période difficile l'année dernière, actuellement le nombre d'add-ons sur addons.mozilla.org qui ne sont pas à jour lors de la sortie d'un nouveau Firefox stable est si faible (bien en dessous de 1%) que le problème n'est plus visible.
Des add-ons puissants qui accèdent directement au cœur du navigateur, ça cadre bien dans la mission Mozilla: permettre aux gens de bidouiller avec le Web, et de prendre le contrôle de leur Web plutôt que de se le faire imposer. Exemples: AdBlock+, Collusion, etc. Ça vaut bien le compromis sur la compatibilité.
[^] # Re: Tu critiques Qt ?
Posté par Zenitram (site web personnel) . Évalué à 10.
C'est rigolo :
- "Chez les autres, c'est inadmissible que ça casse, quelque soit l'excuse des dev', les dev' ont qu'à bien coder".
- "Chez moi, tu comprends, c'est difficile, donc on casse tant pis pour les râleurs qui hurlent qu'on casse"
Je vais citer une personne que tu connais bien : "Il faut aussi préserver à 100.00% la compatibilité binaire descendante".
Bref, paille, poutre…
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . Évalué à 1.
Encore une fois, je pense que Firefox peut proposer une plate-forme d'extensions sans que pour autant les attentes en termes de compatibilité soient les mêmes que pour un toolkit. Il ne s'agit que d'extensions pour une application, pas d'une base pour construire de nouvelles applications. Le vrai "toolkit" implémenté par Firefox est ailleurs: c'est les standards du Web, et là, on préserve la compatibilité de façon très stricte.
[^] # Re: Tu critiques Qt ?
Posté par rewind (Mastodon) . Évalué à 10.
C'est marrant, quand on t'écoute, on a l'impression que Qt et GTK pètent tous les quatre matins. Alors que pas du tout. Simplement, ils ont tous les deux cassé la compatibilité binaire récemment (Qt3 à Qt4 et GTK2 à GTK3) en mettant en place un programme de transition qui a duré plusieurs années. Et avant ça, ils ont conservé la compatibilité binaire en gros une dizaine d'année chacun.
Si on compare à Gecko qui pètait la compatibilité quasiment à toutes les versions, soit tous les 6 mois, tu as raison, c'est incomparable. Je n'ai jamais entendu de développeurs se plaindre de la compatibilité binaire de Qt ou GTK, en revanche j'en ai entendu beaucoup se plaindre de celle de Gecko.
[^] # Re: Tu critiques Qt ?
Posté par Antoine . Évalué à 7.
Et pourquoi ce raisonnement serait-il acceptable pour Firefox et non pour Qt ou Gtk ?
Je sais pas toi, mais personnellement, les applications Qt ou Gtk qu'il m'arrive d'utiliser sont largements plus « puissantes » que les quelques plug-ins que j'ai installés sur Firefox.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . Évalué à 0.
Cf ma réponse à Zenitram ci-dessus.
[^] # Re: Tu critiques Qt ?
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Quand il s'agit de faire des interface (GTK, Qt, tout ça), je suppose que parler de XUl est plus pertinent que de parler de Gecko…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Tu critiques Qt ?
Posté par Thomas Debesse (site web personnel) . Évalué à 5.
Note que rien n'empêcherait Gnome¹ de dire que GTK est son toolkit perso, hein. On pourrait rétorker à la MoFo qu'elle n'a pas à exiger quoique ce soit de Cairo, GTK ou que sais-je. Bref, c'est facile d'exiger des autres en disant « mais moi je n'ai pas les ressources ».
¹ Oui je sais historiquement que G pour Gimp etc. mais bon aujourd'hui, c'est Gnome qui tire et Gimp qu'a du mal à suivre.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Tu critiques Qt ?
Posté par Antoine . Évalué à 9.
Surtout qu'à une époque XUL était clairement marketé comme un toolkit pour tous usages, pas un truc interne à Mozilla.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
Epoque révolue, mais même dans ce cas, ça n'est pas mon propos --- je ne suis pas un représentant de Mozilla ici, c'est pas mon job de justifier tout ce que Mozilla a jamais fait.
[^] # Re: Tu critiques Qt ?
Posté par Olivier Serve (site web personnel) . Évalué à 5.
Et c'est une grosse connerie mais bon, la stratégie n'a jamais été le fort de Mozilla…
[^] # Re: Tu critiques Qt ?
Posté par Gof (site web personnel) . Évalué à 10.
De même que les applications proprios faites avec Qt sont souvent fournies avec une copie de Qt.
[^] # Re: Tu critiques Qt ?
Posté par Gof (site web personnel) . Évalué à 5.
Ça tombe bien. On peut installer Qt3 et Qt4 en même temps.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . Évalué à -1.
Je parlais d'utiliser Qt3 et Qt4 en même temps dans la même application, ce qui suppose en particulier le placement de toute partie incompatible dans un espace de noms séparé.
[^] # Re: Tu critiques Qt ?
Posté par ʭ ☯ . Évalué à 4.
Je me suis demandé pourquoi tu tiens à ça. Et j'ai réalisé que ça permettrait d'utiliser un plugin pour GIMP en GTK1 sur un GIMP en GTK6. Donc oui, c'est tout bon, quand c'est bien fait (voir http://en.wikipedia.org/wiki/DLL_Hell)
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Tu critiques Qt ?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2.
Ça me semble quand même une idée bizarre (et je suis assez doué en idées bizarres àlc), très bizarre… Pourrais-tu nous donner un exemple concret qui démontre l'intérêt de ce genre de manipulation ?
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . Évalué à -2.
Ta question montre que tu n'as lu ni mon journal, ni mes réponses à des commentaires ici qui posaient la même question.
[^] # Re: Tu critiques Qt ?
Posté par Guillaume Knispel . Évalué à 6.
C'est pas parce que X fait Y dans Z et que Z à un grand succès commercial que faire aussi Y dans un contexte != mènera aussi à un grand succès.
D'autre part au moins dans des tas de biblio majeures MS ne permet pas de mélanger deux versions de la même biblio à utiliser par le même processus. En terme d'archi logicielle ça serait complètement tordu.
[^] # Re: Tu critiques Qt ?
Posté par Julien04 (site web personnel) . Évalué à 6.
Et pourtant même Mozilla ne le fait pas pour sa plateforme phare : le web.
https://bugzilla.mozilla.org/show_bug.cgi?id=765645
Cette histoire avait fait le tour du web : suite à la suppression du support par Firefox de certains préfixes CSS propriétaires, un développeur vient se plaindre et va jusqu'aux menaces.
Il est en tord, sauf que la solution qu'il propose (garder un alias, ça ne coute rien !) correspond exactement à ce que tu voudrais : le fournisseur devrait peut être s'emmerder à supporter pendant des années une compatibilité à 100% même si c'est un peu lourd et contre productif.
Ce n'est pas une attaque gratuite, j'ai réellement l'impression qu'on est dans le cas typique et j'adorerais entendre ton point de vue sur cette histoire.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . Évalué à -2.
J'ai (bien entendu) exagéré un peu avec le 100.00%. Disons 99.99% si tu préfères. Il y a toujours des cas où une API doit cesser d'être supportée, par exemple si elle a vraiment trop peu d'utilisateurs pour justifier son coût de maintenance, ou bien si elle est de façon inhérente une faille de sécurité. Mais on ne peut pas comparer ça avec les changements de version majeure de toolkits: quand on entend que "Qt5 est 99% compatible avec Qt4" alors que question compatibilité des binaires existants, ça serait plutôt 0% --- les développeurs de toolkit parlent de compatibilité source alors que les utilisateurs ont besoin de compatibilité binaire pour leurs applications --- je veux dire clairement que le souci de compatibilité du Web en général, et de Firefox en particulier, est plusieurs ordres de grandeur au-dessus de ce que les toolkits offrent. Un site de 1998 a de grandes chances de s'afficher encore correctement dans le Firefox d'aujourd'hui, alors qu'une application de bureau libre de 1998 n'a aucune chance de ne serait-ce que démarrer aujourd'hui.
[^] # Re: Tu critiques Qt ?
Posté par Gof (site web personnel) . Évalué à 5.
Mais quel est l'avantage de la compatibilité binaire? Tu peux toujours faire tourner tes vielles applis avec la version précédente du toolkit. Et quand tu veux des améliorations, bah de toute façon tu recompile.
Et c'est un peu facile de comparer les site web de 1998, qui contenaient juste du texte statique avec quelques images (au mieux des .gif animés) avec une application, beaucoup plus complexe.
D'ailleurs, si je puis me permettre, beaucoup des sites du début des années 2000 étaient "optimisé IE" et n'ont jamais vraiment fonctionné avec ton Firefox.
[^] # Re: Tu critiques Qt ?
Posté par groumly . Évalué à -9.
L'interet c'est de pas se taper 5 differentes versions du meme toolkit a packager/distribuer.
Sur ces 5 versions, 4 ne sont plus maintenues et ne seront pas installer par defaut.
L'interet c'est d'avoir un binaire compile pour Leopard/XP, le prendre et le faire tourner dans LOLcat/Windows 42 sans problemes.
Devoir recompiler une appli a chaque version majeure d'un os, c'est vilain.
Le truc qu'il en ressort, c'est que le seul moyen d'y arriver, c'est d'utiliser le toolkit natif de l'os cible.
Ca requiert d'avoir une appli modulaire, dont la logique metier est a 100% separee de l'interface, et ca requiert aussi d'avoir un vrai toolkit natif surlequel s'appuyer - pas le choix entre 2 douzaines de toolkits venant dans 3 versions differentes version.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . Évalué à -2.
On est bien d'accord que dans les cas simples, où une application n'utilise qu'une version de la bibliothèque, il suffit de distribuer les anciennes versions de la bibliothèque. Encore faut-il le faire. Si une application A utilise LibFoo 1.0 et que LibFoo 2.0 la remplace comme unique version installée dans les nouvelles distros, les développeurs de A vont être submergés de plaintes de clients même si "il suffit de faire apt-get install libfoo-1". Il faut distribuer les anciennes versions par défaut, avec les nouvelles, pour que la sortie de la nouvelle soit réellement indolore pour l'ancienne, tant qu'elle a des utilisateurs.
Ensuite il y a les cas plus complexes où une application a besoin des 2 versions simultanément, non pas parce que ses développeurs sont tordus, mais typiquement parce que parmi les autres bibliothèques qu'elle utilise, certaines sont déjà passées à LibFoo2 et d'autres pas encore. Un exemple de ça est ce que j'ai mentionné dans le journal: les plugins utilisant GTK2 et ne pouvant pas se déplacer dans un processus séparé (Java). De nombreux autres exemples, je suppose, sont à trouver dans les applications de bureau libre où la tradition est de lier dynamiquement à un grand nombre de bibliothèques externes. Dans tous ces cas, en cas de cassure de la compatibilité binaire, en plus de distribuer les anciennes versions, il faut que les différentes versions soient utilisables simultanément.
[^] # Re: Tu critiques Qt ?
Posté par Antoine . Évalué à 2.
Java ne peut pas utiliser XUL ?
[^] # Re: Tu critiques Qt ?
Posté par Julien04 (site web personnel) . Évalué à 3.
Pour l'anecdote, c'est ce qui est fait sur la console Nintendo WII avec les IOS (http://en.wikipedia.org/wiki/Wii_system_software).
Chaque soft (souvent un jeu) est développé pour une version spécifique de la bibliothèque IOS, sans se soucier des versions précédentes ou suivantes. Souvent la version demandée est même hardcodée, donc même si une version plus récente est compatible, elle n'est pas utilisée.
Hormis cas spécial (faille de sécurité par exemple), Nintendo ne met donc pas à jour les IOS existants, mais en publie simplement de nouveaux qui s'ajoutent sur la console.
Ils peuvent être apportés par téléchargement, ou directement par un soft qui en a besoin et qui est donc packagé avec (c'est le cas des jeux qui peuvent donc installer un IOS dont ils ont besoin sans connexion internet).
[^] # Re: Tu critiques Qt ?
Posté par Zenitram (site web personnel) . Évalué à 10.
J'utilise Qt, et j'ai franchement rien à foutre de la compatibilité binaire : je livre la version de Qt qui va bien sous Windows et Mac, et sous Linux c'est la distro qui s'en occupe. En plus, Qt fait les choses très bien, la compatibilité binaire fonctionne entre Qt4.0 et Qt4.8, et ça a été affiché d'origine que Qt passe à 5.0 quand il casse. Pas de surprise, contrairement aux tonnes de surprises que nous a fait Mozilla dans le temps…
Pour un Toolkit, ne t'en déplaise, c'est la compatibilité source qui intéresse les développeurs car les différentes versions sont utilisables (une appli A peut utiliser Qt4 et une appli B peut utilise Qt5, car la plupart des applis ne sont pas assez complexe et proprio pour avoir des plugins binaires non recompilables). Par contre, pour ton boulot à toi, vu que les extensions s'installent sur un binaire de Firefox largement diffusé, la compatibilité binaire est importante, mais bizarrement quand c'est ta paroisse, toutes tes attaques sur les autres sont "irrelevant"…
[^] # Re: Tu critiques Qt ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 0.
Tu veux dire les utilisateurs de logiciels privateurs?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . Évalué à -1.
Oh, j'ai lu ce bug maintenant. Apparemment il s'agit d'une propriété CSS qui a été dé-préfixée. Ceci veut dire que les pages qui ont été cassées étaient des pages programmées pour ne fonctionner que dans une liste finie de navigateurs. Ça, c'est le mal. En gardant la compatibilité avec elles (en conservant ce préfixe -moz ) on ferait le mal, en permettant à des pages Web qui ne marchent que dans Firefox de continuer de proliférer. Il est très important que tous les fabricants de navigateurs adoptent cette attitude stricte face aux préfixes CSS propriétaires, sinon on est repartis pour un scénario à la IE6 avec un Web codé pour le moteur Web dominant du moment.
Ce que cet exemple montre est une différence très importante entre le Web et les autres plate-formes: le Web est multi-implémentation, on y décourage les applications qui ne fonctionnent que sur une implémentation.
[^] # Re: Tu critiques Qt ?
Posté par Antoine . Évalué à 3.
Tu sonnes comme un mormon. Je te conseille d'abandonner la religion, on parle d'informatique, et assurer la compatibilité des API est un service que tu rends à l'utilisateur, pas un péché.
(sans compter que rien ne dit que ces pages « ne marchent que dans Firefox », c'est une supposition gratuite et non-étayée de ta part)
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . Évalué à 4. Dernière modification le 13 octobre 2012 à 18:39.
Tu ne devrais pas prendre ça autant au sérieux, je disais ça comme d'autres commentateurs ici disent "Saymal". Une façon d'exprimer un jugement effectivement moral, tout en le reconnaissant et en le tournant un peu en dérision avec cette formule un peu trop solennelle, "le mal".
[^] # Re: Tu critiques Qt ?
Posté par reno . Évalué à 2.
En théorie, je suis d'accord: le noyau le fait bien, et il n'y a pas de raison que les couches du dessus fassent moins bien, mais en pratique quand tu regardes les efforts/investissements sur Linux par rapport aux couches du dessus, ça n'est pas tellement étonnant que ça ne marche pas..
[^] # Re: Tu critiques Qt ?
Posté par Misc (site web personnel) . Évalué à 3.
Y a des distros qui proposent de garder la comptabilité binaire, comme SLES, RHEL, et surement d'autres. mais bon, pour ça, faut payer, et les gens préfèrent du gratuit.
[^] # Re: Tu critiques Qt ?
Posté par BAud (site web personnel) . Évalué à 3.
combien ça leur coûte de perdre "la comptabilité binaire" ?
sans exemple concret, il est difficile de juger :
[^] # Re: Tu critiques Qt ?
Posté par Misc (site web personnel) . Évalué à 2.
Bah fait un sondage autour de toi, demande pourquoi les gens utilisent pas de version payante comme SLES ou RHEL sur leur desktop.
# monde libre vs monde propriétaire
Posté par antistress (site web personnel) . Évalué à 10. Dernière modification le 12 octobre 2012 à 19:02.
L’obsession du toolkit dans le monde libre par rapport au monde proprio tient aussi dans le fait que dans le monde libre on partage les briques sous-jacentes. Du coup entre un lecteur vidéo KDE et un lecteur vidéo GNOME par exemple, il peut très bien n'y avoir que le toolkit de différent. Donc la tentation est grande de prendre l'infrastructure et d'y ajouter "simplement" le bon toolkit car on ne créé pas vraiment un nouveu logiciel mais plutôt une nouvelle interface "à peu de frais".
La situation est un peu plus complexe cependant car il y a aussi le respect des HIG en plus du choix du toolkit. Je ne citerai pas des applications Amarok-like en GTK+ à destination du bureau GNOME dont la seule différence semble être le toolkit, sans égard pour la HIG de GNOME par exemple.
Après Qt s'intègre pas si mal dans un environnement GTK il faut lui reconnaître ça, c'est un bon caméléon : cf VLC. Honnêtement VLC en GTK+ ne s'intégrerait pas mieux qu'actuellement faute de respecter les HIG de GNOME.
(Journal très intéressant, je vais aller lire les précédents)
# Aldo il a la classe avec le bon toolkit
Posté par antistress (site web personnel) . Évalué à 6.
Et je voulais dire aussi que le dilemme du toolkit (+ le respect des HIG) c'est peut-être justement ça qui donne la classe à Aldo sous GNU/Linux, parceque Aldo, quand, en 2005, il était sous Windows XP avec ses skins pour Winamp et qu'il a vu GNOME, il s'est dit : ça c'est la classe internationale ce bureau. Et depuis il est resté sous GNOME !
(Vous aurez compris que je parle de moi)
[^] # Re: Aldo il a la classe avec le bon toolkit
Posté par BAud (site web personnel) . Évalué à 3.
faut-il encore afficher les avatars :)
# firefox et KDE : l'exemple
Posté par Adrien . Évalué à 8.
J'ai bien rigoler sur le passage sur firefox.
En effet quand on parle « toolkit », ou boîte à outils de développement en français, je pense direct à firefox. Contrairement aux applications GTK traditionnelles, firefox est l'une des seules applications qui fait un peu n'importe quoi sous KDE :-)
Le côté on s'en fout d'une interface unifiée et cohérente, la preuve on n'y pense pas en Web ou sous Windows est également assez pitoyable. Avoir des logiciels très intégrés est un atout indéniable, n'est pas d'ailleur une des raisons du succès de MacOS ?
Enfin bon quand on commence à vouloir « devenir majoritaire sur le marché », je sors le popcorn :-) Quelques questions : pourquoi devenir majoritaire ? il y a une course ? Et quel est ce fameux (fumeux?) marché ?
[^] # Re: firefox et KDE : l'exemple
Posté par ʭ ☯ . Évalué à 9.
Sans cette course à la majorité, on en serait encore à simuler le fonctionnement d'IE6 sur webkit et gecko…. Il faut être majoritaire pour imposer un standard, Mozilla a permis de rendre majoritaire les standards W3C.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: firefox et KDE : l'exemple
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 1.
C'est bien pour ça qu'il se refuse à implémenter les standards pour imposer ses propres technos moisies ! (WOFF contre SVG fonts, APNG contre MNG, etc etc.)
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: firefox et KDE : l'exemple
Posté par Benoit Jacob (site web personnel) . Évalué à 1.
Si tu penses vraiment que WOFF est une 'technologie moisie' comparée aux fontes SVG, tu es à côté de la plaque, mais je penses que tu trolles.
[^] # Re: firefox et KDE : l'exemple
Posté par zebra3 . Évalué à 0.
On s'en fout de ce qui est moisi ou pas.
Le fait est que les SVG Fonts sont un standard du w3c, et que Mozilla fait exactement la même chose que Microsoft : refuser un standard et proposer sa propre solution.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: firefox et KDE : l'exemple
Posté par cedric . Évalué à 2.
J'ai pas l'impression que tu es jamais participe a l'elaboration d'un standard ni meme tente d'en implementer un. Ils arrivent tres tres frequement qu'un standard soit defini par une societe unique qui tente de le forcer sur les autres, car elle y trouve son intret. Mais un standard n'a de valeur que si tous les acteurs acceptent de le suivre. Donc il y a une limite d'acceptabilite qui fait que certain standard n'arrive jamais a perce, car ils sont effectivement trop moisi.
[^] # Re: firefox et KDE : l'exemple
Posté par zebra3 . Évalué à 3.
Sauf que SVG Fonts est un standard du w3c.
C'est tout de même assez paradoxal d'aller à l'encontre du w3c quand on veut faire de l'évangélisation des standards.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: firefox et KDE : l'exemple
Posté par Nonolapéro . Évalué à 3.
C'est juste que Mozilla n'apprécie que les standards qui l'arrange.
http://linuxfr.org/users/windu2b/journaux/le-whatwg-veut-faire-avancer-html-5-dans-son-coin
[^] # Re: firefox et KDE : l'exemple
Posté par Benoit Jacob (site web personnel) . Évalué à 5. Dernière modification le 15 octobre 2012 à 15:45.
Ce que Cédric a écrit est vrai, et le fait qu'il ait été moissé à -2 en dit long sur les abus du système de modération de LinuxFR. Certains standards n'auraient jamais dû devenir des standards parce qu'ils sont incapables d'offrir ce qu'ils prétendent offrir. C'est le cas des SVG Fonts, qui ne sont à la rigueur appliquables qu'aux langues à écriture simple (alphabet latin, japonais, etc) et certainement pas aux écritures complexes (arabe, persan, langues indiennes). Voir ce commentaire de Behdad:
https://bugzilla.mozilla.org/show_bug.cgi?id=119490#c49
Ce n'est pas à Mozilla qu'il faut s'en prendre, c'est aux idiots qui ont conçu une technologie inadaptée au Web et qui l'ont fait accepter par le W3C.
[^] # Re: firefox et KDE : l'exemple
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 1.
Est-ce qu'on peut faire des animations en WOFF ? Des couleurs ? Des dégradés ? Des effets de masque ? Etc.
Non.
Donc j'ai compris, il faut s'en prendre "aux idiots qui ont conçu une technologie inadaptée au Web et qui l'ont imposée aux détriments d'autres qui sont complémentaires".
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: firefox et KDE : l'exemple
Posté par reno . Évalué à 3.
Majoritaire on s'en fout ok, mais qu'il y ait suffisamment de gain d'argent sur le desktop pour pouvoir avoir
1) la compatibilité binaire des toolkits
2) une maintenance correcte des couches basses (pilotes, X,..) qui sont en manque chronique de developpeurs
3) des applications un peu plus "finie" (un exemple parmis d'autre: Gimp évolue très,très lentement)
ça ne serait pas du luxe..
Après bien sûr, ça se mord la queue, il faut 1+2+3 pour avoir des gains d'argents sur le desktop..
[^] # Re: firefox et KDE : l'exemple
Posté par Misc (site web personnel) . Évalué à 3.
soit faut plus de codeurs, soit faut plus de gens pour payer.
Plus de codeurs, bah faut par exemple redonner au C ses lettres de noblesses ( au lieu de pondre 15 languages de templates pour 30 blogs sur 45 frameworks web ).
Plus de gain d'argent, pourquoi pas commencer par payer pour avoir une distro sur son desktop, au lieu de prendre les trucs gratos ? Bien que je pense pas que ça serve à grand chose vu les montants en jeu, filé des thunes à Canonical serait une idée. Payer une souscription RHEL Desktp, ou SLES, ou autre, ça serait envoyer un signe.
[^] # Re: firefox et KDE : l'exemple
Posté par reno . Évalué à 0.
Pas d'accord, en C tu fais un fois deux en nombre de ligne de code par rapport à un langage comme C#(par exemple).
Après le problème de langages de haut niveau, c'est qu'on n'en a pas vraiment de bon, et même en se contentant des langages correctes existant leurs implémentations sont pas terrible: librairies réduites (le support de Qt particulièrement..), GC pas temps réels, compilateurs avec bug, etc.
[^] # Re: firefox et KDE : l'exemple
Posté par saltimbanque (site web personnel) . Évalué à 2.
tu fais 1 x 2 en nbre de lignes de code
Tu fais 2 en nombre de lignes de code
Waouh en C on code en 2 lignes, c'est super efficace!
[^] # Re: firefox et KDE : l'exemple
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2.
L'Hebdogiciel le faisait déja il y a 25 ans.
[^] # Re: firefox et KDE : l'exemple
Posté par Adrien . Évalué à 5.
Mais le libre représente plein de chose. Sur certains « marchés » il est très bien positionné (serveur, supercalculateur, etc.). Regrouper tout le libre sur un seul « marché », dont il faudrait être majoritaire est stupide. Être majoritaire implique d'avoir une seule solution, qui est prépondérante. Comment dans le libre imposer une seule solution ?
Pour le bureau, je te rejoins sur 1) et 2) qu'une importance plus grande serait bénéfique. Par contre sur le troisième point, je ne suis pas d'accord : là encore, on retombe dans une vision unique. Une très grande partie de particulier et d'entreprise vont sans doute préférer une évolution lente, pour ne pas perdre ses repêres. Nous voyons donc encore des besoins différents, donc des « marchés » différents. Entre avoir un gimp suffisamment ergonomique pour retoucher ses photos le dimanche et avoir un gimp pro, ce sont deux objectifs totalement différents. Perso je pense que de nombreuses applications libres sont très bien finies et tiennent tout à fait la comparaison avec la « concurrence »…
# Hop
Posté par Marotte ⛧ . Évalué à 6.
Est-ce que tu peux dire à Dédé de rapporter sa boîte à outils parce qu'Yvonne elle arrive à pas forcer la porte de la véranda ?
[^] # Re: Hop
Posté par Antoine . Évalué à 3.
Fallait pas acheter une véranda privatrice™ !
# La bonne blague !
Posté par liberforce (site web personnel) . Évalué à 10.
Alors pour le coup, je vois plein de commentaires disant "oh oui, comme tu as raison". Et bien ce ne sera pas mon cas, je suis en complet désaccord avec toi.
Et pourquoi ? Parce que pendant des années il était difficile d'avoir une bonne intégration dans un desktop en utilisant des applis de toolkit différents. Ce n'est pas qu'une histoire de thème, mais aussi de design: une appli KDE et GNOME n'ont pas du tout la même tronche, même avec un thème identique. Fût un temps, tu n'avais pas 2 Go de RAM sur un desktop, mais plutôt moins de 512Mo, et utiliser des toolkits différents sur ton système te donnait une pénalité en termes de consommation mémoire. L'utilisateur averti sous Linux avait donc tendance à chercher des applications utilisant le même toolkit, parce qu'elles allaient souvent visuellement mieux ensemble, et en plus sa machine allait plus vite !
Aujourd'hui, GTK ou Qt ont des systèmes de thèmes assez puissants, et c'est surtout le design de l'application qui les distingue. Mais ça, ça dépend du développeur de l'appli, pas du développeur du toolkit.
Tu pense que l'utilisateur Windows sait ce qu'est un toolkit ? Non, il voit juste un truc moche qui ressemble pas au reste, mais il est habitué, depuis le temps. Personne ne proposait mieux, ou il ne savait pas qu'il pouvait avoir mieux ailleurs. Une appli moche sous Windows, on s'y fait si elle marche (ex: VLC). Mais ça reste moche. Comme un salon fait de bric à brac. Il peut être très confortable, il est pourtant moche. Le même aussi confortable et joli, je ne suis pas sûr que les gens n'aiment pas.
C'est le seul point où on est d'accord. Parfois le design de l'application est adapté pour s'intégrer au mieux à l'environnement de bureau, mais dans pas mal de cas c'est une pure copie.
Mais il ne faut pas oublier que GTK est né d'un réel besoin: la licence propriétaire de Qt. Une fois que l'écosystème autour de GTK était créé, et que Qt est devenu libre, que fallait il faire ? Tuer GTK ?
Les thèmes sont là pour ça… Si tu n'as qu'un version utilisant un autre toolkit que ton préféré, bin tu fais comme sous Windows: tu fais avec. C'est la différence entre préférence et exigence.
Le problème ici, c'est les parts de marché. Si Linux avait 20% de parts de marché, et KDE 40% de ceux là, ç'aurait paru bien plus intéressant. Mais doit-on en déduire que forcément tout ce qui se fait sous Linux (qui représente 1% de PDM) n'a aucun intérêt ? 1% c'est déjà pas beaucoup, pourtant Mozilla fournit bien des binaires pour Linux, c'est bien qu'elle y trouve un intérêt, non ? La fragmentation des toolkits, cela ralentit juste la progression vers la masse critique. Mais de la même manière que tu ne peux pas demander aux fabricants de matériel de faire des drivers pour tous les OS, même les plus exotiques, il y a un moment où la communauté doit faire une partie du boulot…
Donc d'un côté tu utilises une bibliothèque externe ce qui te permet d'économiser en développement et en maintenance, mais de l'autre tu te plains qu'elle évolue et que migrer prend du temps de développement qui vous est précieux.
Tu en profites pour tacler les équipes de développement de GTK, comme si eux avaient des ressources illimitées. S'ils n'ont pas fait cette compatibilité GTK2-GTK3 dans le même binaire, c'est pour les mêmes raisons que vous: pas assez de ressources. L'autre raison étant que dans GTK2, les modifications et les obsolescences de composants se sont faites cycle après cycle. Une application GTK2 qui a été mise à jour au fur et à mesure des obsolescences est directement compatible GTK3 ! Il est aussi à noter que le but était de virer dans GTK3 tous les composants obsolètes de GTK2. Il y a 8 ans de stabilité d'ABI entre les 2 versions ! Au final, tu te plains juste qu'une bibliothèque dont tu dépends… évolue. Bienvenue dans le monde de l'informatique. Tu penses peut être que s'il n'y avait eu qu'un seul toolkit sous Linux il n'y aurait pas eu ce boulot à faire ?
Tu parles de la charge de portage, mais ne prends pas en compte la charge de développement et maintenance de l'équivalent dans Chromium. Ah, et je ne veux pas te gâcher ton week end, mais GTK 4 est dans les cartons, avec sûrement fusion avec Clutter, et pour le coup, ça va faire bien plus de changements que pour la migration GTK2 → GTK3.
Quand je vois sous Windows tout le monde qui réinvente la roue parce que chacun ait sa solution proprio dans son coin, je ne suis pas sûr que ton approche soit la bonne. C'est bien… si tu as du pognon et les compétences pour maintenir ça chez toi. Sinon, tu délègues ! En plus, Google aurait eu du mal à se distinguer en disant ah, bah in utilise les mêmes technos que Firefox, mais on est mieux. Bah non, ça se passe pas comme ça, ça s'appelle la concurrence. Tout comme il y a concurrence entre Qt et GTK. Entre Windows et Linux.
Bref, ça s'appelle le choix.
Tu pars du principe que ce serait plus simple que le développeur d'application fasse tout à sa sauce, et pour moi c'est du syndrome NIH. Tu pars du principe que le pari de l'intégration est perdu d'avance, et là je ne suis profondément pas d'accord.
[^] # Re: La bonne blague !
Posté par Bruce Le Nain (site web personnel) . Évalué à 9.
Et j'en rajoute une couche :)
Euh, je cherche vraiment les chiffres pour la "petite" minorité. Tu as les liens ? Car tu sembles oublier Mint KDE, OpenSuse, Mageia, Rosa, Debian, Kubuntu, PCLinuxOS, Arch, Chakra… qui ont des proportions non négligeables d'utilisateurs KDE.
Je rejoins le commentaire plus haut, tu compare quelque chose qui date d'il y a 7 ans à quelque chose d'actuel dans un contexte différent. Compares plutôt Qt4 vers Qt5. Pour le "plus petit" faudra m'expliquer le rapport.
Bon, alors deux infos facilement trouvables via wikipedia :
article Qt
Article Qt Development Frameworks
Tout ça pour dire, faut arrêter de fuder avec des bouts d'information.
Tiens, ce n'est pas ce qu'ils se sont dit ici par exemple. Et d'ailleurs, est-ce vraiment toolkit-agnostique comme raisonnement ?
L'idée générale de l'article est très bonne je pense. D'ailleurs, Canonical semble beaucoup plus souple dans le choix de ses toolkits (EFL à une époque, Qt, Gtk…) mais prôner l'ouverture signifie aussi arriver à ne pas revenir dans le travers de démonter un toolkit pour en encenser un autre.
Quand je lis ça, j'ai l'impression de lire "les cuisiniers ont tort de vouloir qu'un plat soit entièrement sucré ou salé, - même s'il est bien sûr évident que le sel est bien meilleur pour la santé tout en étant plus polyvalent, que le sucre est ringard, trop polluant à produire alors que le sel est si facile à récolter, si bien que le sucre devrait être abandonné - mais surtout, rappelez vous peu importe le sucre ou le sel, l'important est que le plat soit bon"
# Je suis 100% d'accord
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Moi, c'est affaire de toolkit et de bureau intégré, ça me fait chier !
J'utilise un bureau wmii car très rapide et pratique, firefox et thunderbird car ca rox, nedit (ou geany mais pas aussi souple pour l'édition en parallèle de vim, lowriter pour l'odt, pour les photos, jbrout, geeqie. Je me souviens avoir utilisé en son temps xcdroast… et pour la musique clementine !
Bref, tout cela pour dire que le mélange de toolkit ne pose pas de soucis. Surtout que GNOME et KDE prennent autant en RAM que tous les autres réunis ;-)
L'expérience utilisateur, je trouve que c'est un bien grand mot. Je préfère de bonnes applications pour des vrais besoins.
Un truc qui me gonfle, c'est quand une application gnome ou kde doit lancer tout son fourbit pour fonctionner… J'ai déjà dis ici que j'aimais pas tous ces démons de dialogue entre applications. Je trouve que c'est souvent sur-évalué. D'ailleurs, la tendance avec les portables est au cloisonnement !
Les bureaux gnome et kde aurait du plus travailler sur les bibliothèques communes quittes à améliorer au passage X (par exemple sur le copié coller). Il y a eu des tentatives intéressante comme xprint par exemple. Ensuite, il y a des mauvaises bonnes idées comme les copié coller intelligent (OLE). En pratique, cela résiste très mal au envoi par courriel et cela fait bien longtemps que je n'en ai plus vu la couleur entre documents.
L'utilisateur lambda va dans le menu application et lance au max 10 applications. Le choix se fait sur celle qui préfère, pas sur leur intégration graphique. Aucun de mes utilisateurs sous gnome n'a de bouton en lançant matlab, voire des daubes utilisant mono et des binaires PE32 (ansys).
# La libstdc++
Posté par Michaël (site web personnel) . Évalué à 2.
En plus de l'arrivée tardive du standard de la STL déjà relevé par quelqu'un d'autre ici, on peut aussi observer que les classes conteneur de la STL ne sont pas exemptes de défauts (pas de traits pour l'insertion ou retrait des objets, donc il faut toujours savoir si on utiliser des pointeurs, des références, etc.) et configurables (si on veut adapter l'allocateur de mémoire à la classe, il vaut mieux définir ses propres conteneurs au dessus de ceux de la STL).
Pour info je n'ai jamais écrit une seule ligne avec Qt, donc qu'on ne surestime pas ma ferveur pour la cutie!
Sinon toolkit peut se traduire par jeu ou trousseau d'outils.
# Penser "utilisateur"
Posté par goom . Évalué à 6.
Moi j'utilise des logiciels, j'utilise windows et linux et dans cette "affaire" je ne dirais que :
- l'utilisateur (pas le geek utilisateur) s'en fout du toolkit, du moment qu'il trouve un intérêt au logiciel
- attention au toolkit qui fait des trucs moches. Là je pense clairement à GTK et à sa boite de dialogue pour ouvrir ou enregistrer un fichier que je trouve mauvaise et pas ergonomique. Là sous windows, j'ai comparé la boite de dialogue "ouvrir un fichier" de Firefox, Thunderbird, Scribus, TuxGuitar, Excel, µtorrent, VLC, Audacity, Dia et très clairement celle de cette dernière application est très différente (les autres sont proches voire identiques), à l'ergonomie différente et de mon point de vue déroutante et pas engageante (d'une manière générale, je trouve les applications GTK pas très jolies)
Peut être qu'il faut surmonter cette obsession, mais il me semble qu'il ne faut pas occulter qu'un toolkit peut influer sur le look d'une application et induire un a priori négatif.
# tu vas vite en besogne !
Posté par Thomas Debesse (site web personnel) . Évalué à 7. Dernière modification le 12 octobre 2012 à 22:30.
Au contraire, je comparerais volontiers le développement des bureaux libres et les plate-formes mobiles. Les projets comme Gnome ou KDE ont beau avoir un certain âge, ce sont toujours des projets fragiles. D'une certaine manière on pourrait se désoler qu'ils soient toujours trop jeunes ! Aussi, les bureaux libres évoluent beaucoup. C'est pourquoi, quand une brique change, on préfère porter l'appli qui fonctionnait avec l'ancienne brique pour qu'elle fonctionne avec la nouvelle brique, pour continuer à déléguer le débugage de la brique…
En fait je remplacerait jeune par fragile, et très vite par rien du tout, on pourrait dire :
Et on pourrait dire de la même manière :
Si tu trouves que le monde du mobile n'est pas un exemple pertinent pour les raisons évoquées, le monde du bureau libre est un exemple tout autant impertinent. Il faudra trouver d'autres raisons, parce qu'au contraire, cette comparaison est juste et bien trouvée !
Parce que ces deux mondes sont fragiles mais vivants, alors il est intéressant voire nécessaire de mutualiser et de ne pas réinventer la roue.
Au contraire, dans un monde installé (sclérosé ?) comme celui de Windows, il est facile de faire n'importe quoi, il serait peut-être même parfois plus facile et moins risqué de réinventer la roue ou bien de ne pas évoluer vers des technologies plus modernes…
ce commentaire est sous licence cc by 4 et précédentes
# metro
Posté par CrEv (site web personnel) . Évalué à 5.
Et comment c'est passé le passage à metro ?
Est-il possible d'utiliser en même temps, dans le même binaire, les anciennes api windows et les nouvelles ?
[^] # Re: metro
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
Le comportement de Microsoft sur Metro me fait penser, et je ne suis pas le seul, que Microsoft a vraiment oublié les raisons de ses succès commerciaux et qu'ils vont se planter cette fois-ci.
[^] # Re: metro
Posté par CrEv (site web personnel) . Évalué à 3.
ok, donc au final y-a-t'il vraiment une différence entre supporter/faire évoluer les différentes versions de gtk et celles des apis windows ?
Car à te lire on dirait que le libre say nul sur ce point mais finalement c'est pareil pour windows 8, donc ça n'aurait finalement que peu à voir avec le libre.
Et d'ailleurs :
Ok, donc en fait mozilla a fait un choix, qui s'avère pas génial. Mais c'est la faute du libre, des développeurs de bureau libres ?
Mozilla n'était pas assez grand pour faire ses propres choix ?
Le handicap, côté interface, c'est pas plutôt xul tout simplement ?
[^] # Re: metro
Posté par BAud (site web personnel) . Évalué à 2.
c'est une question rhétorique, dans les deux cas les développeurs concernés ont accès au code source et à la plateforme de génération (bon avec un peu moins de liberté de diffusion pour les seconds).
# laissez tomber GTK
Posté par Troy McClure (site web personnel) . Évalué à 4.
Laissez tomber GTK et utilisez JUCE pour firefox ! http://www.rawmaterialsoftware.com/juce.php , au moins ce toolkit est adapté et largement testé pour les plugins. Je crois que des gens l'ont déjà utilisé pour faire des plugins binaires pour browsers.
(bien sûr ce n'est pas une suggestion sérieuse, il s'agit d'un toolkit relativement simple et limité, il n'a pas toutes les fonctionnalité et l'integration que peuvent offrir gtk ou qt)
# Est-ce vraiment le passage de toolkit Qt3 --> Qt4 qui a nuit à KDE?
Posté par reno . Évalué à 4.
Pas mal de plaintes sont venues aussi de Nepomuk (activé par défaut un démon immature et gourmand en ressources ce n'est pas très malin..) et des activités, de la réécriture du bureau en Javascript qui a induit des perturbations (assez réduite il me semble), bref tout n'est pas lié à Qt loin de là..
J'ai utilisé NEdit (qui utilise Lesstiff) dans un desktop KDE (de mémoire c'est vieux), c'était la seule application qui me posait des problèmes de copier/coller et elle avait un look&feel différent des autres, utiliser plusieurs toolkit ça a des inconvénients aussi!
[^] # Re: Est-ce vraiment le passage de toolkit Qt3 --> Qt4 qui a nuit à KDE?
Posté par bubar🦥 (site web personnel) . Évalué à 4.
Sans chercher de midi à quatorze heure, pas mal de plaintes sont également venues de ce simple fait :
Kde4 ne fonctionnait pas correctement. De très nombreux bugs, partout, du plus simple mais déjà énervant au plus chiant corrompant le profil. Et c'est tout…
Après, même d'un point de vue utilisateur, cela se comprends facilement : la difficulté et la taille de la tâche sur la quantité de développeurs réalisant cela. Les distributions ont donc fait le choix d'intégrer tôt kde4, afin d'augmenter le nombre de retours utilisateurs. Et là, la théorie s'est cognée au mur de la réalité : non, il n'est pas possible de transformer les utilisateurs en debuggers. Pas de cette manière, surtout pour un projet si gros qu'est un bureau.
Ensuite on peux râler sur les "purs players" que sont les simples utilisateurs ne contribuant en rien qu'en utilisant, et leur faire peser le poids de la culpabilité, sans cesse ressasser sur des sites fréquentés par eux, du fait qu'ils ne contribuent pas. J'ai pas l'impression que cela améliore les choses.
Gnome a opté pour une méthode différente : celle de proposer un bureau à minima mais fonctionnel (avec de plus le rechargement à chaud de celui ci si une extension/wtf le faisait partir en quenille) Un bureau à minima et fonctionnel, donc des râlantes sur le manque de fonctionnalités. Mais pas de râlantes sur la stabilité. Malheureusement cela semble ne pas suffire également, voir la déferlante de critiques à l'égard du projet Gnome et de son bureau.
Deux méthodes différentes, un résultat semblable aujourd'hui : deux bons bureaux, deux projets libres magnifiques (avec une petite touche spéciale pour le projet Kde, qui est le seul qui soit exclusivement communautaire). Et -surtout- un tour de roue plus loin, nous sommes de nouveau dans une situation comparable à 2002~2004 : des "purs utilisateurs" qui en ont un peu marre du reste (enfermement chez apple, metro chez windows ajouté à un rejet grandissant de ms) mais qui sont néanmoins satisfait de ce qu'ils utilisent. Ils sont juste "à l'écoute" d'un éventuel challenger.
Le bureau libre arrivera t il à faire (re-)venir ses utilisateurs ? En sachant qu'il s'agit probablement essentiellement d'utilisateurs esthètes et exigeants, en plus ? Le bureau libre veut il vraiment çà : avoir des utilisateurs ? Ce n'est pas un bullshit, mais une vraie question, sur laquelle cet excellent journal de Mr Jacob n'intervient pas mais la fait postulat de base. Or je ne suis certain qu'il s'agisse vraiment d'un postulat de base pour tous…
ps : pour nepomuk, c'est malheureux, d'autant qu'il y avait quelques années plus tôt l'expérience mandrake qui avait déjà fait remonter cela (il s'agissait d'un eq de strigi/wtf, outil d'indexation de contenu de fichiers, le premier à être livré sur un bureau). Poourtant tout le monde (de nombreux autres projets depuis) ont pourtant reproduit la même chose : un service qui consommait beaucoup par défaut, alourdissant bureau, usages voir autonomie)
[^] # Bureaux
Posté par Arthur Accroc . Évalué à 3.
Ah ? Même pour le 3.0 ?
Parce que je l’ai essayé une fois sur la Fedora 15. Une seule fois sur ce compte, parce que quand j’ai réessayé la fois d’après, je me suis retrouvé aussitôt sur le prompt de connexion. Bon, entre les deux, j’ai dû installer des extensions (celles empaquetées par la distribution) pour voir si ça rendait l’interface fonctionnelle. Enfin, je n’ai pas essayé de déboguer le problème, c’était juste un test avant de mettre éventuellement ce bureau à mes utilisateurs, et j’en avais assez vu.
Moi, j’aurais dit deux bloatwares. Au niveau purement utilisation, l’intérêt du libre c’est de ne pas avoir une machine aussi lente qu’il y a dix ans parce que le système (au sens large) s’est alourdi pour compenser l’augmentation de vitesse du matériel. À condition de ne pas prendre KDE ou Gnome, parce que sur ce point, ils copient les systèmes propriétaires : comme les versions 2 et 3 commençaient à très bien tourner, ils ont sortis de nouvelles versions majeures bien plus lourdes et moins pratiques.
L’utilisateur, ce dont il a réellement besoin, c’est pouvoir accéder à ses fichiers et lancer ses logiciels. Le système et le bureau ne sont que des moyens pour ça. S’ils se mettent en travers en bouffant une bonne partie des ressources (disque, mémoire ou CPU), ils usurpent leur place.
Bon, je modérerais ma critique concernant KDE, dans la mesure où ses applications sont en général un peu plus légères que leurs équivalentes non KDE, donc si l’on n’utilise que du KDE, on amortit les usines à gaz qu’il lance en tâche de fond. Mais c’est un choix auquel on n’est pas encouragé s’ils cassent la plupart des applications quand ils changent de version du bureau…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Est-ce vraiment le passage de toolkit Qt3 --> Qt4 qui a nuit à KDE?
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
Tiens, je trouve cet argument pertinent… Personnellement je me retrouve complètement dans la définition d'utilisateur esthète et exigeant. L'esthétisme et l'exigence sont des critères très important dans mes choix, en fait quand je râle à l'utilisation d'un windows ou d'un mac OS, c'est quasi systématiquement à propos de l'esthétisme, je pourrais râler sur le libre/pas libre, mais finalement, pour un simple usage, ce n'est pas le premier argument. Alors je suis conscient de faire partie d'une niche, mais je ne vais pas reprocher au projet Gnome de travailler sur ma niche, au contraire !
Par contre, on pourrait faire un reproche historique aux projets de majeurs de bureau libre d'avoir depuis si longtemps et pendant tout ce temps donné toujours plus le goût de l'intégration et d'un esthétisme cohérent. Effectivement, si aucun bureau libre n'avaient eu cette volonté de cohérence et avaient toujours été de joyeux bazars rivalisant de désintégration, on subirait plus facilement un outil qui réinventerait pour la 1000ème fois les HIG et les couleurs.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Est-ce vraiment le passage de toolkit Qt3 --> Qt4 qui a nuit à KDE?
Posté par Gabin II . Évalué à 1.
Je ne comprend l'usage ni le style. Vous êtes deux sur LinuxFr à utiliser le terme "bullshit" de cette façon, toi et Patrick_G.
Aussi, j'aurais tendance à dire qu'il s'agit ici d'un mot féminin, donc l'accord est faux.
Bref, contente toi de ne parler qu'une langue à la fois.
# Les iles
Posté par cedric . Évalué à 10.
Je suis tellement pas d'accord avec toi, aussi bien sur ton analyse technique que sur les objectifs de ton message que je ne sais meme pas par ou commencer. Disons la technique.
Donc commencons par Qt, honneur au plus age. Qt existe depuis une epoque ou le C++ n'etait pas portable avec la STL et qu'il etait difficile de trouver un compilo qui s'en sorte avec. Cela explique beaucoup de chose dans son design. Apres il y a une faute fondamentale pour un toolkit. Il y a une regle, qu'ils ont decouvert que trop tard dans leur histoire, si on veut fournir une API/ABI stable au cour du temps, on utilise le C. Le C++ qui a du mal a avoir une ABI stable pose deja un probleme de base, mais le fait que les champs prives finissent dans les headers rend impossible de fournir la moindre stabilite a long terme. LLVM l'a bien compris, seul l'api C sera stable. Cette erreur est a mon gout fatale pour un toolkit. On peut rajouter que le C++ a aussi un coup d'utilisation CPU et memoire superieur a du C, mais c'est globalement irrelevant pour cette discussion.
GTK n'a pas ce probleme, et ils ont ete capable de faire vivre leur API sur le plus long terme. Par contre, le design meme de l'architecture de ce toolkit pose de gros probleme de performance et d'efficacite, hors dans un monde ou tout se dirige vers l'embarque, GTK se revele completement inadapte. Les evolutions de ce toolkit ont essaye de combler le probleme, mais ca releve plus de la rustine que d'une veritable solution. Ce qui tend a rendre ce toolkit obsolete (et par la meme, la desaffection des developpeurs du coeurs du biniou).
Maintenant tu prend en exemple Chrome parce que eux, ils n'ont pas pris de toolkit, donc ils s'en sortent mieux que Mozilla. Comment dire, c'est une excuse facile ! Deja les problemes d'integration et les bugs de Chrome sont nombreux. Copier/Colle qui foire une fois sur deux, le rendu des textes dans un autre alphabet que occidentale qui sont loufoque, … Pour Mozilla, le principal probleme a mon sens c'est leur code source et leur gestion de la communaute. Je n'ai regarde que le code de SpiderMonkey et consort, mais c'est vraiment calamiteux et la communaute des developpeurs autre que Mozilla a vraiment du mal a participer (voir meme a juste utiliser leur techno). Ca s'explique par l'age de la bete, mais quand on voit v8 ou WebKit, c'est une tout autre histoire… Faudrait commencer par faire le menage chez soi avant d'accuser les toolkits de pas vous aider.
Dans le meme genre, tu peux prendre aussi LibreOffice/OpenOffice qui ont aussi leur propre toolkit. Une vrai bouse qui rame et prend son temps meme avec un i7, des Go de ram et un SSD. Et je parle meme pas de l'integration correct a X (l'integration correct au desktop kde/gnome etant trop loin…). Developper son propre toolkit, ca donne ca. Des couts de developpement supplementaire, des erreurs de design, car on n'a pas l'experience des gens qui font des toolkits donc on "loupe" des trucs. Et avec le temps ca ralentit completement le developpement d'un projet en augmentant la masse de developpeur necessaire pour le maintenir en vie. Surtout que l'excuse le toolkit, il fait pas ce qu'on veut ou ils cassent tout dans le temps, c'est vraiment petit quand on est une societe avec les moyens ou un gros projet libre. On peut influencer voir participer (concept nouveau dans le logiciel libre) dans le developpement des projets utilises en dependences. Vraiment une idee de fou.
Enfin sur le fond, ton message est de dire que c'est la faute au toolkit si Linux n'a pas pris sur le desktop. Qu'il n'en faut que un pour que l'on reussisse a s'imposer. Bah meme si on avait eu un super toolkit de la mort qui tue, unique, performant, joli, portable, lege et stable pour les 50 ans a venir, on n'aurait pas plus pris de part de marche sur le desktop. Regarde juste Apple, ils n'arrivent sur le desktop que par le cote (les vents d'ipod, iphone et ipad drivant les ventent de matos) et malgre tout ca, ils en sont a 7 ou 8% de part de marche mondial. Oh, et ils ont aussi un toolkit unique et du beau matos. Le probleme du desktop, c'est qu'il y a une arme de milliard d'individu et de societe refractaire a tout changement qui ne changeront jamais leurs habitudes. La strategie de l'attaque frontale, genre troll qui fonce dans le tas, c'est sur c'est heroique, ca fait un beau film d'action et de sympathique scene de bataille. Mais a la fin, le troll, il meurt. Il faut toujours s'installer la ou l'ennemie n'est pas, se fortifier et s'etendre. Et uniquement a la fin attaquer la cible principale, si elle existe encore.
De plus, tu pars du principe qu'avoir des applications isolees, des iles qui echangent des donnees de temps en temps, c'est la solution. La preuve, Apple, Microsoft et le web font ca et ca leur reussi. Sauf que une des raisons pour la reussite de Gmail, c'est que tu as en meme temps, l'IM, le calendrier, la recherche, la preview de document, … Le tout bien integre. Parcontre, tu n'as plus le choix. Et globalement aucun lecteur de mail classique ne s'en approchent (a part Kontact, mais ils arrivent pas a gerer mes 7Go de mails). Tu loupes un pan entier de ce qui est l'objectif d'une partie des developpeurs du libre. Quand on a fait le deuil de la domination du monde, qu'on arrete de vouloir concurrencer des gens qu'on ne peut pas concurrencer. Alors ce pose la question de qu'est-ce qu'on peut faire mieux ? Qu'est-ce qu'on peut ameliorer par rapport a l'existant et qui attirera suffisamment de gens, plutot des developpeurs si possible, dans notre petite forterresse ?
La reponse que le libre a donnee a cette question, c'est l'integration quit a avoir 5 ou 6 desktop. C'est sur, ca correspond pas a Mozilla, qui vit dans un monde ou tout est isole et ou la communication entre chacun est limite. Mais et pour le coup, je trouve ce qu'a fait le projet KDE vraiment pas mal dans ce domaine. Ils n'ont rien standardiser pour la communication entre leurs applications, ils ont juste developpe leur technologie adhoc et integre joyeusement tout ca. Et je suis pas un developpeur de KDE, je participe au projet Enlightenment, mais ca m'empechera pas de reconnaitre les reussites des autres projets.
D'ailleur, j'ai oublie de faire ma charge sur les standards. C'est truc, c'est une calamite, suffit de regarder FreeDesktop, le jour ou j'y trouve un standard de qualite, bien ecrit, bien pense et utile, je t'offre le champagne. Les standards sont une maniere a un projet d'imposer ses choix a un autre en etant le premier a ecrire la spec, car les temps entre les projets ne sont pas les memes. Il n'y a pas un expert en permanence disponible dans tous les projets de desktop pres a negocier n'importe qu'elle sujet de standard. Resultat, le standard, il se fait tout seul dans son coin et 6 mois plus tard on se rend compte qu'on veut implementer la meme feature, donc on regarde ce nouveau standard pour se rendre compte que c'est une catastrophe… Et on perd du temps a l'implementer de la maniere la moins catastrophique qui soit. Forcement c'est encore une solution a minima qui aide personne et impact tout le monde.
[^] # Re: Les iles
Posté par ahuillet (site web personnel) . Évalué à 4.
T'es gentil mais quand tu espères nous faire lire un pavé pareil, mets au moins des accents !
[^] # Re: Les iles
Posté par Gof (site web personnel) . Évalué à 4.
Il n'a pas lu le 1ᵉʳ journal de notre ami sur les conseils aux libriste : celui qui rappelle que l'usage des accents en français n'est pas facultatif.
[^] # Re: Les iles
Posté par cedric . Évalué à -5.
Je vie dans un pays ou je rencontre un Francais tous les quinze jours. Mon clavier n'a aucun accents et 90% des gens avec qui je communique journalierement ne parle pas francais. Donc non, je prends pas le temps de gerer les accents pour les peu de fois ou j'ecris en Francais. Faut pas croire que tout le monde vit et parle en Francais. Il y a un monde en dehors de la France…
[^] # Re: Les iles
Posté par Thomas Debesse (site web personnel) . Évalué à 8. Dernière modification le 13 octobre 2012 à 16:26.
Sur LinuxFr, tout le monde lit et écrit en Français ! Peu importe si mon voisin parle latin !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Les iles
Posté par Benoit Jacob (site web personnel) . Évalué à -3. Dernière modification le 13 octobre 2012 à 18:49.
Moi aussi. La solution que j'ai retenue pour pouvoir poster sur LinuxFR sans me faire emmerder est la disposition English-international.
Cette obsession des détails (accents) alors que le français est malmené de façon bien plus profonde sur LinuxFR (anglicismes incontrôlés et inutiles) me fait toujours un peu hésiter à y retourner.
Ce qu'il faudrait ça serait un équivalent français de LWN.net, un site où le commentateur moyen a un réelle expérience du logiciel libre et est là pour parler de sujets qu'il connaît. J'ai l'impression que la majorité des commentateurs ici n'ont pas d'expérience en développement logiciel.
[^] # Re: Les iles
Posté par Nonolapéro . Évalué à 4.
Moi non plus je ne parle pas aux cons, ça peut les instruire.
[^] # Re: Les iles
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 14 octobre 2012 à 08:49.
Ce n'est pas un détail. C'est dur à lire.
Et oui, vous avez le droit à utiliser une vraie disposition clavier comme US International, comme certaines personnes US le font avec respect des lecteurs.
Ensuite, ben suffit d'avoir un correcteur orthographique correct, il corrige automatiquement les accents et gère plusieurs langues à la fois (ce n'est pas le cas des produits Mozilla).
C'est sûr qu'en commençant par insulter les gens, tu vas te faire des amis.
Peut-être que justement si, ils développent, et ne sont simplement pas d'accord avec toi sur la nécessité d'avoir Qt3 et Qt4 compatible binairement et ne sont aussi pas d'accord avec toi quand tu défends ton employeur en lui pardonnant tant de choses…
Beaucoup de monde a une expérience en développement logiciel. Par contre beaucoup de monde n'est pas développeur Mozilla non plus, donc a d'autres idées sur ce qui est bien ou pas bien (et ça a pas mal râlé sur tout ce que Mozilla casse en envoyant chier les développeur tiers, l'hôpital qui se fout de la Charité) chez Mozilla en ayant plus de recul… Ici, je vois surtout un développeur logiciel qui pardonne bien beaucoup de chose à son employeur et qui invente des problèmes plus gros que la réalité chez les autres.
Descend de ton piédestal.
[^] # Re: Les iles
Posté par Michaël (site web personnel) . Évalué à 3.
Si jamais tu as tout de même envie d'essayer de saisir les accents, je te propose de lire la discussion suivante:
Comment taper les accents sur un clavier Qwerty:
https://linuxfr.org/users/bjacob/journaux/comment-taper-les-accents-sur-un-clavier-qwerty
Ma méthode préférée est la touche compose:
https://linuxfr.org/users/bjacob/journaux/comment-taper-les-accents-sur-un-clavier-qwerty#comment-1377436
Envoyé de mon clavier QWERTY NMB (Designed for Windows 95, dit le fabriquant!)
[^] # Re: Les iles
Posté par koxinga . Évalué à 3.
Je suppose donc que tu as un clavier QWERTY, il suffit d'activer la disposition US-international pour avoir tous les accents disponible `+a=à, '+e=é, "+o=ö, etc. Les autres lettres demandent un petit apprentissage, comme Alt+, pour ç.
10% de francophones dans tes contacts, c'est déjà pas mal, cela vaut le coup d'investir cinq minutes pour changer ta disposition de clavier et enfin écrire en Français au lieu d'ecrire en Francais.
[^] # Re: Les iles
Posté par Gof (site web personnel) . Évalué à 6.
Bha c'est pareil pour moi. Donc je trouve ta critique assez déplacée.
J'écris en français sur linuxfr, et j'essaye de corriger toute mes faute pour qu'il y ait le moins possible de mots souligné en rouge dans la prévisualisation. (Je sais que je laisse quelques (beaucoup?) de fautes).
[^] # Re: Les iles
Posté par zebra3 . Évalué à 3.
Oui, mais là tu écris sur un site ou tu rencontres des Français tous les jours.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Les iles
Posté par steph1978 . Évalué à 4.
il y a le manque d'accents mais il y a aussi le pseudo phonétique : "c'est" pour "ces"; ça frise le skyblog.
le phonétique, ça existe et ça a aussi ses règles, ça ne permet pas de faire n'importe quoi.
en gros, j'ai apprécié tes arguments même si je ne suis pas d'accord avec tout.
mais ce massacre de l'écriture me fait mal à la tête à force de devoir tout relire deux fois.
si tu ne peux/veux pas écrire correctement en français, écris en anglais (en globish en fait), je préfère.
[^] # Re: Les iles
Posté par saltimbanque (site web personnel) . Évalué à 6.
On me signale que les spectateurs demandent plus de détails techniques.
[^] # Re: Les iles
Posté par cedric . Évalué à 2.
Simplement GTK n'utilise pas un canvas de rendu statefull pour ces widgets ou scene graph. Cela rend impossible toute amelioration de performance un tant soit peu pousse. De plus, le nombre de contributeur a GTK est actuellement bas, et c'est un fait. Coder ce genre de chose est tres difficile. Et non, il ne suffit pas de mettre tout ca dans des textures et balance ca un GPU pour que ca fasse un gentil tour de magie.
[^] # Re: Les iles
Posté par Gof (site web personnel) . Évalué à 7.
Et moi je suis pas d'accord avec toi:
Toll N° 1: C vs. C++
On le voit souvent ce troll. Mais le C++ est pour moi mieux que le C.
C'est un langage d'aussi bas niveau que le C, qui offre les mêmes possibilité de performenc et d'être « près de la machine » mais tout an étant beaucoup plus expressif. On est donc beaucoup plus productif en C++ qu'en C.
Et merci a des toolkits tel que Qt d'offrir une API utilisable, c'est vraiment un bonheur.
Oui, c'est un peu plus compliqué de garder la compatibilité binaire au cour du temps. On en a déjà discuté. Mais est-ce que c'est un goal en soi? pas vraiment. D'ailleur, même les bibliothèques en C cassent souvant la compatibilité binaire (openSSL, libpng, gtk, …)
J'ai fait un projet utilisant LLVM, et j'ai utilisé l'API C++ et j'en suis bien contant.
Et une autre équipe avait essayé de faire un truc similaire avec l'API C, ils ont déjà passé pas mal de temps à re-wrapper l'api C dans du C++, et au final leur truc marchait mal.
Quand on a envie d'utiliser le C++ pour être productif, on aime utiliser des API en C++. On aime pas utiliser le C.
Hahaha, mais bien sur, et C++ tues aussi plus de bébés chat que le C. Et le C permet de meilleur performences sexuelles. C'est prouvé :-)
Euh.. GTK aussi change son API. GTK2 à duré 9 ans. et Qt4 8 ans.
[^] # Re: Les iles
Posté par cedric . Évalué à 1.
Question d'habitude :-) Et j'ai vu assez de code C ecrit en C++ pour te dire que la tres grande majorite des devs "C++" ne saient pas en faire ni en tirer benefice. Maintenant, tu prend un developpeur experimente en C ou en C++, je pense qu'ils auront la meme productivite. Quand au cout du C++, il y en a un que tu ne peux meme quand tu es bon eviter, c'est le link. Le nombre de symbole dans les libs C++ etant juste dantesque, tu te retrouves avec des temps de demarrage hallucinant et non ameliorable. Pour le reste, quelqu'un qui connait tres bien le compilo et comment le modele objet du C++ fonctionne sera tout a fait capable d'avoir les meme perfs qu'en C, je n'en doute pas.
De mon point de vue, le C++ donne un gain a cour terme, mais avec le temps, en tout cas pour tous les projets industriels que j'ai vu, ca tend vers le rustinage et l'horreur de maintenance. Et plus le turn over de l'equipe est important, plus cela tourne au cauchemar. C'est juste une conclusion de mes observations. Maintenant, si tu as une petite equipe stable de 4, 5 personnes, le resultat peut etre tres impressionant dans le temps. Mais c'est rarement un cas qui arrive dans la pratique (a part pour certain projet libre qui tende a maintenir un equipe core stable sur de longue periode).
Et j'ai aussi utilise l'API C et C++ de LLVM, le fait quel marche ou pas, et completement anecdotique vu qu'on a les source (on peut resoudre les bugs facilement). Maintenant la version C++ a eu une vie plus courte que la version C…
Oh ! J'ignorais tout ca, cool ! Plus serieusement, entre l'utilisation des objets a tout va, des templates, des allocations "caches", la tendance est a l'embonpoint. Le fait que beaucoup d'operation memoire soit implicite, fait que si on manque d'attention, ca consomme vite plus. Dans la theorie, tu dois pouvoir arriver au meme en faisant attention, dans la pratique peu de projet y arrive, car il faut etre vraiment tres tres conscienceux.
D'apres ma memoire, l'ABI du C++ a ete casse avec gcc 4.2 en 2007, donc ca peut pas faire 8 ans ou alors tu m'ecris du futur.
[^] # Re: Les iles
Posté par Gof (site web personnel) . Évalué à 5.
Ah oui c'est vrai.
(Mais on parlais ici d'API, pas d'ABI)
[^] # Re: Les iles
Posté par Gof (site web personnel) . Évalué à 10.
Il est vrai que dès qu'une classe a une fonction virtuelle, on se retrouve avec les vtable et les symboles RTTI (Runtime Type Information)
C'est effectivement un problème.
Petits rappel théorique pour ceux qui sont intéressé: (cedric, tu peux passer ce paragraphe)
Quand on a au moins une fonction virtuel dans une classe, le compilateur crée une vtable (une seule par classe dans tout le programme, pas une par instance de chaque classes). C'est une table qui contient un pointeur vers chaque fonction virtuelle, et aussi des information RTTI.
RTTI permet de faire fonctionner les exceptions, les dynamic_cast ou typeid
Le problème c'est que ces tables de pointeur de fonction doivent être "rellocated" au moment ou la bibliothèque est chargée en mémoire. En effet, les bibliothèques sont en général compilée en "Position Indépendent Code". Ça veux dire que le code est chargée a une position différente en mémoire à chaque fois, donc les pointeurs de fonction ont toujours une adresse différente. Dans le code en lui même, la plupart des référence à d'autre partie du code sont fait de manière relative. Mais les tables virtuelles doivent être en absolue. Donc les bibliothèques contiennent une "table de rellocations" qui donne les instructions au loader pour réécrire toute ces tables au lancement.
Un autre problème vient du fait que les symboles doivent en général doivent être exportés. Et comme ELF permet de remplacer des symboles (avec LD_PRELOAD), le loader doit retrouver chaque symbole par son nom dans les tables de symboles
Un des principes derrière C++ est « zéro overhead ». Mais cette règle est un peu violée par le RTTI.
Une solution est de faire compiler -fno-rtti. Qt n'utilise pas RTTI dans son propre code (pas d'exceptions, pas de dynamic_cast). Mais par défaut il est compilé avec parce que les utilisateurs veulent pouvoir utiliser ces fonctionnalités.
Mais ceux qui utilise Qt sur embarqué peuvent désactiver RTTI.
Par contre, le problème est un peu pareil en C dans une bibliothèque comme GTK, qui réécrit des « table virtuelles » a la main.
[^] # Re: Les iles
Posté par rewind (Mastodon) . Évalué à 2.
Il y a le problème inverse avec Boost : on ne peut désactiver ni le RTTI, ni les exceptions parce que Boost les utilisent les deux.
[^] # Re: Les iles
Posté par Benoit Jacob (site web personnel) . Évalué à 6. Dernière modification le 13 octobre 2012 à 19:10.
La solution à se problème est -fvisibility=hidden.
Pour voir à quel point tu es loin de la réalité, fais un démarrage à froid de la version stable de Firefox (je ne garantis rien sur les binaires de ta distro, je parle des binaires mozilla) avec profil par défaut. Ça devrait démarrer en 2 secondes maxi si tu as une machine correcte, alors que libxul.so est une immense bibliothèque C++ et que Firefox ne peut rien afficher sans qu'elle soit en grande partie chargée.
Ensuite de nombreuses applications C++ sur bureau libre ont d'autres problèmes, mais c'est leur faute:
- Chargement d'un grand nombre de bibliothèques différentes, avec leurs propres dépendances. Le gros truc à éviter.
- Grand nombre de constructeurs d'objets globaux/statiques.
- relocations inutiles
- voir le blog de Glandium
[^] # Re: Les iles
Posté par cedric . Évalué à 4.
Personnellement, je trouve 2s sur une machine recente insupportable. Je peux demarrer un toolkit complet en 80ms sur un cortex A8. Quand je clique sur une icone, je veux que avant que mon doigt est quitte le bouton, avoir l'application a l'ecran. Les splash screens etant a mon sens l'aberation ultime d'une application. Et oui, je concois que des fois, on passe du temps a charger plein de module comme GIMP, mais pourquoi je ne peux pas en meme temps commencer a manipuler mon application et avoir un chargement asynchrone…
J'ai un laptop qui avec un noyau un peu tune boot en 2s jusqu'au gestionnaire de fenetre, si une application prend dessus plus de 1s a se lancer, c'est inacceptable de mon point de vue.
[^] # Re: Les iles
Posté par groumly . Évalué à -10.
Rajoutes par dessus que les sessions durent en general 30 a 120 secondes sur mobile, 2s juste pour charger l'appli est clairement redhibitoire…
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Les iles
Posté par Benoit Jacob (site web personnel) . Évalué à 3.
C'est pour ça que Firefox Mobile a été réécrit pour pouvoir afficher son UI instantanément sans attendre le chargement effectif du moteur de rendu des pages Web.
[^] # Re: Les iles
Posté par groumly . Évalué à -10.
Je croyais que reecrire c'etait mal?
Ensuite tu montres par cette anecdocte que le toolkit est loin de n'etre qu'une bete boucle d'evenement.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Les iles
Posté par zebra3 . Évalué à 1.
J'ai voulu essayer pour comparer, mais vu que mon système est en 64 bits et que vous ne fournissez pas de binaire adapté, je n'ai pas pu tester. Avant de venir se plaindre des autres, faudrait commencer par suivre l'évolution technologique, aujourd'hui tous les OS et processeurs PC sont 64 bits.
En tout cas il ne me restait plus qu'à lancer Iceweasel 16.0.1 sur ma Debian après avoir mis de coté les profils existants et purgé les caches.
Bilan : 26 secondes. Je ne sais pas ce que tu entends par « machine correcte », mais cette machine a trois ans et est tout ce qu'il y a de plus correcte, j'y fais tourner des VM. En tout cas, je commence à avoir une idée sur qui est le plus éloigné de la réalité (même j'en avais déjà une idée avec la prise en charge des archi 64 bits).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Les iles
Posté par Antoine . Évalué à 4.
Ça fait des années que Mozilla fournit des binaires 64 bits :
http://download-origin.cdn.mozilla.net/pub/mozilla.org/firefox/releases/16.0.1/linux-x86_64/
[^] # Re: Les iles
Posté par zebra3 . Évalué à -1.
Alors ça fait des années qu'ils pourraient le mettre sur leur page d'accueil, parce qu'un obscur site FTP ça fait pas très officiel.
En plus, l'archive est nommée exactement comme la version 32 bits, c'est vachement clair.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Les iles
Posté par Antoine . Évalué à 3.
J'ai pris ce site FTP parce que c'est le miroir européen, mais tu le trouves aussi sur le FTP d'origine :
ftp://ftp.mozilla.org/pub/firefox/releases/16.0.1/linux-x86_64/
Personnellement, le fait qu'elle soit dans un répertoire contenant "x86-64" me suffit. Si tu as un doute, un petit coup de "file" sur l'exécutable.
[^] # Re: Les iles
Posté par Zenitram (site web personnel) . Évalué à 3.
Ce n'était pas la remarque.
Je ne vois rien ici :
https://www.mozilla.org/en-US/firefox/all.html
C'est "all" dans l'URL, non?
Tu as de la chance, chez moi le nom du répertoire n'est pas gardé quand j'enregistre le fichier.
C'est un choix, mais du coup je vois pas trop pourquoi avoir gardé le numéro de version, il est aussi indiqué dans le nom du répertoire et en cas de doute il y a un fichier ChangeLog à lire et hop…
[^] # Re: Les iles
Posté par zebra3 . Évalué à 1.
Et en partant de http://www.mozilla.org ? C'est tout de meme par là qu'on commence quand on veut télécharger un logiciel.
Je savais très bien que Mozilla compilait aussi Firefox en 64 bits, mais tant que ça n'est pas mis en avant, c'est que c'est du dev. Et je n'avais pas envie de tester sur du dev.
Moi pas. Si tout le monde sous Linux fait la distinction, c'est qu'il y a une raison.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Les iles
Posté par Michaël (site web personnel) . Évalué à 3.
Tant qu'on argumente de façon raisonnable, il n'est point de troll!
D'un côté, tu as à peu près raison en ce qui concerne les performances: il n'est pas impossible en C++ d'écrire du code bien près de la machine… à ceci près que pour ce faire tu vas laisser tomber toutes les abstractions que tu peux pour ne travailler explicitement que sur des entiers, des pointeurs (au lieu d'itérateurs), et des flottants, si tu fais du calcul numérique.
À mon sens, on néglige trop souvent les interfaces permettant d'écrire des applications complexes dans plusieurs langages différents, à savoir
les ponts avec le C (de nombreux langages peuvent s'interfacer avec le C, notamment Lua, Python, Caml, Scheme/Guile, probablement Perl, … et C++ !)
les ponts avec le Shell (Unix, pipes et parfois tout simplement le système de fichiers).
D'un autre côté, je ne suis pas du tout d'accord en ce qui concerne l'accroissement supposé de la productivité. Le langage C++ a trois gros défauts:
la présence de types de données redondants (char* vs. std::string, pointeurs et références, conteneurs et tableaux, sans oublier les équivalents dans les différentes bibliothèques qu'on va utiliser!)
écrire une bonne hiérarchie d'objets est éminemment difficile car il faut introduire les bonnes abstractions: la méthode naïve consistant à associer une méthode à une classe en fonction de ses arguments (i.e. le C méthode(a,b) est remplacé par le C++ a.méthode(b)) donne des classes fourre-tout qui se comportent comme des programmes où toutes les variables sont globales!
le langage (privé de l'alchimique bibliothèque Boost) a plus de 7 types fonctionnels distincts et incompatibles entre eux (une fonction a -> b ->c peut être globale, membre statique d'une classe arbitraire, membre de la classe a, variantes avec
const, variantes avec b =voidcomme type d'argument) qui oblige à écrire des boucles for. N'ayant pas écrit de boucle for pendant des années (Caml) j'ai redécouvert ce plaisir avec le C++…La façon productive d'écrire une boucle
forest bel et bienfor x in container do f(x)et pas du tout ce que proposent les itérateurs![^] # Re: Les iles
Posté par Guillaume Denry (site web personnel) . Évalué à 5.
En ce qui concerne le fait de stabiliser l'API en cachant les champs privés, Qt utilise abondamment le PIMPL idiom, ce qui permet quand même de limiter largement les dégâts.
# ergonomie et arguments de vente
Posté par Antoine . Évalué à 1.
Et pourquoi est-ce que les bureaux Linux n'adopteraient pas la même stratégie ? Après tout c'est ce que fait Gnome Shell, avec succès.
[^] # Re: ergonomie et arguments de vente
Posté par Arthur Accroc . Évalué à 4.
Gnome Shell, l’ergonomie ? J’ai failli m’étouffer. Tu es sérieux, on c’est juste pour lancer un troll ?
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: ergonomie et arguments de vente
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
Disons que l'ergonomie est aussi une affaire d'esthétisme, et que les goûts, les couleurs et la culture, c'est pas complètement universel.
Il y a des gens qui sont content de l'ergonomie de Gnome, moi par exemple. Donc quand je lis « Gnome Shell, l’ergonomie ? J’ai failli m’étouffer » sans autres arguments, je reçois cela comme un troll. Je ne pense pas que se limiter à répondre « c'est ridicule ! » ou bien « t'es sérieux ? » fasse avancer le schmilblick.
ce commentaire est sous licence cc by 4 et précédentes
[^] # [Troll] Gnome 3
Posté par Arthur Accroc . Évalué à 5.
Je ne nie pas l’importance de l’esthétisme, mais pour moi l’ergonomie et l’esthétisme sont deux choses différentes.
Côté esthétisme, la première version de Gnome 3, sous Fedora 15, était livrée avec un fond d’écran limite déprimant (je ne sais pas si ça s’est amélioré depuis), alors que les autres bureaux en avaient un moins moche. Ce n’était pas pour arranger le tableau.
Sans extension ?
Parce jusqu’ici, les échos d’utilisateurs satisfaits que j’ai eus, c’était avec extensions et ils n’envisageraient pas de l’utiliser sans.
La superbe ergonomie de Gnome 3 a juste causé :
– un fork à partir de Gnome 2,
– deux remplacements de Gnome Shell par des distributions (Unity et Cinnamon),
– des tas d’extensions pour ramener des fonctionnalités normales,
– des critiques en masse (dont celle de Linus),
– des départs d’utilisateurs vers Xfce, KDE ou autres.
On n’avait jamais vu ça à ce point-là, même pour KDE 4 (pour lesquels les reproches étaient l’instabilité et la lourdeur plutôt que l’ergonomie).
Ce n’est pas le premier logiciel auquel je penserais comme exemple d’ergonomie réussie…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: [Troll] Gnome 3
Posté par Thomas Debesse (site web personnel) . Évalué à 7.
J'ai envie de répondre « prisme ».
J'ai envie de dire que c'est inhérent à un projet libre de cette ampleur, et au changement : il y a suffisamment de personnes qui n'ont pas envie de changer (et c'est un droit légitime). Le fait de forker ici ne signifie rien sur la nouvelle ergonomie, cela signifie seulement que l'ancienne ergonomie est manquante pour ceux qui veulent la garder. l'ergonomie de Gnome2 n'est plus disponible dans les dépôts Gnome, mais cela ne juge en rien de la qualité ou non de la nouvelle. Toute personne qui ne souhaites pas changer (et c'est un droit) ne sera pas satisfait par Gnome3, mais quelques que soit la nature des modifications de Gnome3. C'est tout à fait normal que quelqu'un qui veuille l'ergonomie de Gnome2 ne soit pas satisfait par l'ergonomie de Gnome3 ou de KDE4 ou de E17 qui n'est pas l'ergonomie de Gnome2, cela ne veut pas dire que l'ergonomie de Gnome3, KDE4 ou de E17 soit pourrie.
Tu sais que le projet Gnome lui-même a déjà utilisé Enlightenment comme WM ? qu'Ubuntu a proposé depuis longtemps compiz à la place de metacity ? qu'Ubuntu a toujours ajouté des tas d'applets "Ubuntu" à Gnome ? En quoi le fait qu'une distribution aie envie de proposer autre chose que Gnome signifie que Gnome soit pourri ? Est-ce que le fait que des distributions proposant KDE proposent aussi Firefox comme navigateur signifierai que KDE sainul ?
Les distributions comme Ubuntu font toujours des patchwork. Ubuntu a toujours rajouté à Gnome des outils maison, c'était peut-être moins visible que le Shell, mais l'expérience Ubuntu/Gnome a toujours été différente de l'expérience Gnome de base. LinuxMint a toujours proposé une expérience différente que l'expérience Gnome de base : dispositions des panneaux et applets propres à Mint. De Gnome, LinuxMint ne gardait que les applis et le panel, quasiment tout ce qui était dans le panel était du LinuxMint, pas du Gnome. Ubuntu et LinuxMint ont toujours proposé une expérience basée en partie sur les technos Gnome, mais toujours avec des variations plus ou moins fortes.
La question du fork Cinnamon est une autre question, ce n'est pas une question d'ergonomie, c'est une question de code. On peut se demander pourquoi LinuxMint pouvait remplacer l'ergonomie Gnome2 par l'ergonomie LinuxMint avec les outils Gnome2 sans trop les modifier, et pourquoi LinuxMint ne peut plus remplacer l'ergonomie Gnome3 par l'ergonomie LinuxMint avec les outils Gnome3 sans trop les modifier. C'est une question de code, pas d'ergonomie ni d'expérience utilisateur. L'ergonomie a toujours été différente sur LinuxMint, c'est la manière de pouvoir fournir cette ergonomie différente qui a changé.
Je n'utilise habituellement pas d'extension. Il m'est arrivé d'utiliser deux extensions : l'une qui permet de modifier la luminosité de l'écran au pointeur, une autre qui m'affiche la température du proco. La première est utile sur ma tablette et était déjà un applet sous Gnome2, le second est franchement accessoire et était également un applet sous Gnome2. Je suis très content du bouton 'Accès universel' par défaut parce que sur ma tablette cela me permet d'activer le clavier virtuel en tactile. En usage bureautique cela ne me dérange pas car avec un écran de 1920px de large, on s'en moque un peu. Il m'arrive parfois de tester une extension pour avoir les contrôles multimédia dans le menu du son, chose qui a toujours été une extension sous Gnome2. Bref, aucune extension pour ramener des fonctionnalités que Gnome2 avait.
Pour ce qui est de la bureautique, Linus n'est qu'un power user comme un autre. Sa renommée sur les systèmes d'exploitations ou la gestion décentralisée de sources ne lui donne aucune autorité dans le domaine de la bureautique. Concernant Gnome ou KDE, l'avis de Linus n'a pas plus de valeur que le mien. Il a juste plus de visibilité que moi, c'est tout. La visibilité n'est pas la légitimité ni l'autorité.
Je n'ai encore vu personne migrer de Gnome vers XFCE ou KDE ou autres. Les seuls que je vois changer sont ceux qui de toute manière changent de temps en temps « pour voir ». Par contre je connais plusieurs personnes qui migrent d'Ubuntu Unity vers Ubuntu Gnome. J'ai déjà utilisé XFCE par le passé, j'ai plusieurs fois essayé KDE4, en vain, j'ai à chaque fois échoué pour des raisons d'instabilité, de lourdeur et d'ergonomie, aussi d'ergonomie. Aujourd'hui KDE4 me serait peut-être plus satisfaisant, mais j'ai trouvé Gnome3 utilisable avant que je trouve KDE4 utilisable.
Si tu n'as que des arguments à la « j'ai vu », « j'ai pas vu », bah tu n'as pas d'autres arguments qu'un prisme. Moi aussi je peux faire plein de
« j'ai vu », « j'ai pas vu ».
Oui sans extension.
Tu vois, depuis plus d'un an, par curiosité, je suis les évolutions de Gnome au fil de l'eau. Cette curiosité m'empêche d'utiliser les extensions facilement, parce que c'est un peu comme les extensions firefox : elles sont validées pour les versions stables de Gnome, et je n'ai pas envie de les valider ou les porter à la main. J'étais déjà satisfait par les versions stable sans extension pour mon usage quotidien, mais c'est ma curiosité qui n'était pas satisfaite. Et clairement, je n'avais pas besoin des extensions au point que j'ai pu sacrifier leur usage. Vraiment, le fait de ne pas pouvoir les utiliser ne m'a pas fait hésiter longtemps. Si je revenais à un Gnome Stable, je pourrais certes me réjouir d'utiliser les extensions, mais comme je ne m'en sers pas…
Il faut faire 'achement gaffe avec les « on dit » sur Gnome Shell, on n'entend que les mécontents, les aigris, et parfois même des personnes qui n'en savent rien et qui colportent mal des rumeurs. Par exemple, sur DLFP j'ai lu une fois sur un journal que Nautilus allait retirer la possibilité de « tapper » un nom de fichier dans la liste des fichiers. J'ai bondi, je me suis insurgé, j'ai grondé parce que c'était une fonctionnalité dont je me sers très souvent, cela me permet de trier les fichiers par date tout en sachant les retrouver par leur nom. Et bien en fait on m'a menti : on n'a pas retiré cette fonction, on l'a amélioré. Alors peut-être que du coté du code, on a retiré in vieux code pour en rajouter un nouveau, mais au niveau de l'expérience utilisateur, ça c'est amélioré. Avant quand je cherchais un fichier dans une grande liste en tapant son nom, je ne voyais qu'un fichier si la liste n'était pas triée par nom, aujourd'hui nautilus me restreint l'affichage aux seuls fichiers qui correspondent à ce que je tappe. Voilà un exemple de coups-de-gueule à base de « je vois qu'ils retire » sans regarder « mais qu'ont-il mit à la place », de cette histoire n'est resté que le coup de gueule, et je n'ai vu personne féliciter ses avancées. Aussi, ceux qui n'utilisent pas Gnome3 peuvent facilement colporter les erreurs et autres trolls, il n'y a que ceux qui utilisent Gnome3 qui peuvent rétablir la vérité, et les utilisateurs content sont toujours moins nombreux que les trolls qui n'y connaissent rien et ne font que relayer des bêtises parce que c'est excitant.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: [Troll] Gnome 3
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
Hum, petite modification, on dirait que je dis que XFCE est lourd et instable et inergonomique, ce que je n'ai pas voulu dire
J'ai écrit :
Je voudrais plutôt réécrire :
À noter que si quelqu'un trouve Gnome3 trop minimaliste, je ne comprendrai pas vraiment qu'il lui préfère XFCE. C'est d'ailleurs la raison qui a poussé Debian a remplacer Gnome par XFCE comme bureau par défaut : Gnome3 est devenu un bureau trop gros pour être proposé comme bureau à l'installation par défaut. Debian a préféré le minimalisme d'XFCE en l'opposant à Gnome3.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: [Troll] Gnome 3
Posté par Lizzie Crowdagger (site web personnel) . Évalué à 3.
«À noter que si quelqu'un trouve Gnome3 trop minimaliste, je ne comprendrai pas vraiment qu'il lui préfère XFCE.»
Des critiques que j'ai lues (et pu formuler, d'ailleurs) sur Gnome 3, c'est plutôt le manque de «configurabilité» par défaut qui est reproché que le minimalisme. (Oui, y'a des extensions, mais c'est chiant de devoir installer une extension pour changer le thème du shell, par exemple)
«C'est d'ailleurs la raison qui a poussé Debian a remplacer Gnome par XFCE comme bureau par défaut : Gnome3 est devenu un bureau trop gros pour être proposé comme bureau à l'installation par défaut. Debian a préféré le minimalisme d'XFCE en l'opposant à Gnome3.»
Je suis pas sûre que ce soit une décision définitive, il me semblait avoir compris qu'une autre option était de changer l'outil de compression et que c'était pas évident que XFCE serait l'environnement par défaut.
# Plugins ?
Posté par Tonton Benoit . Évalué à 6.
Perso j'aime avoir une interface cohérente, des icônes assorties, des notifications qui apparaissent toujours au même endroits…
J'aime pas, sous Android, quand un programme se permet d'être flashy avec des icônes genre diamants alors que le thème de base est sobre, c’est même une raison de ne pas l'utiliser pour moi !
Par contre, j'ai toujours utilisé des applications Qt sous Gnome (Texmaker, K3B…) et GTK sous KDE (QuodLibet, The Gimp…) et je trouve que ça ne pose plus de problèmes insurmontables depuis pas mal d'années déjà. Il existe des thèmes qui permettent d'accorder l’ensemble sans que cela ne jure trop.
Bien sûr ça n'utilise pas les boites de dialogues natives, ou en tout cas pas sans bidouilles, le fond de l'icône de QuodLibet n'est pas transparent dans la barre des miniatures de KDE (mais ça marche pour d'autres applications GTK, donc à voir).
Mais pourquoi cela viendrait forcement du tookit ? Concernant l’apparence c'est déjà facile d'appliquer un thème qui rendra le rendu très proche entre les deux tookits. Pour les boites de dialogues pourquoi pas une bibliothèque d'abstraction qui se charges d’appeler la version native ?
Pour QuodLibet par exemple l'affichage dans la boite de miniature GTK est déjà un plug-in, il ne maque que des mains pour développer la version Qt, Gnome, Ubuntu…
Y'a déjà des trucs qui marchent, MPRIS2 permet de contrôler à peu près n'importe-quel lecteur audio, une couche de compatibilité dans KDE permet de gérer correctement les notifications des applications GTK, quand je place la barre de menu en haut dans KDE ça fonctionne aussi sur les applications GTK…
Pour moi les bureaux Unix doivent garder leur côté intégré, mais cette intégration doit moins dépendre du toolkit et plus de normes freedesktop et d’architecture logiciel pluggables.
# Commentaire supprimé
Posté par Anonyme . Évalué à -1. Dernière modification le 15 octobre 2012 à 00:27.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Toolkit envy
Posté par Olivier Serve (site web personnel) . Évalué à -1.
Et donc, impossible de faire des widgets spécifiques qui seraient inconnus du WM, bravo !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Toolkit envy
Posté par Olivier Serve (site web personnel) . Évalué à -1.
Ah, je croyais que les contrôles/widgets étaient gérés par le WM, maintenant c'est possible aussi dans l'appli. Ils vont donc être spécifiques à l'appli, avec leur apparence propre (indépendante de celle du WM) : retour au point de départ.
Les widgets personnalisés sont souvent des évolutions de ceux existants, mais si tu n'as pas la main sur leur représentation, tu ne peux plus le faire.
[^] # Re: Toolkit envy
Posté par liberforce (site web personnel) . Évalué à 2.
Je ne vois pas le rapport, tu peux faire un widget personnalisé qui utilise un thème, le même que pour le système. Cette idée de déplacer le toolkit dans la pile logicielle n'est pas nouvelle. Il y avait par exemple eu la tentative avortée de Y-Windows qui mettait les widgets au niveau du serveur d'affichage..
# Libristes only? J'en doute fort...
Posté par freem . Évalué à 1.
J'en doute fort, parce que .NET n'est ni plus ni moins qu'un outil bâtard entre le framework et la machine virtuelle de JAVA, selon moi.
Windows, exemple tellement cité, regorge de frameworks faisant le café… donc, les libristes ne sont pas les seuls.
En fait, je pense même que c'est l'exacte raison du succès de JAVA, et de .NET: l'abondance de fonctions au sein de la même
merdechose.Après, pour le reste, effectivement à lire les ressentis envers FF, un dev mozilla qui défends son patron me semble avoir assez peu à dire, au vu de ce que je vois sur DVP.
Après, je suis pas dev web/extensions donc il se peut que je me trompe quand j'ai l'impression que la stabilité des APIs laisse à désirer.
Ensuite, certains points d'intégration ne sont pas complexes à gérer, même sans librairies. (l'emplacement de la conf utilisateur, par exemple, ou il suffit de récup le contenu d'une variable… je serais heureux que plus de logiciels le fassent au lieu de pourrir mon ~/)
J'ignore si FF les respecte, cela dis, cela fait bien longtemps que je ne l'utilise plus. Utiliser une bdd pour stocker des favoris me fais assez tiquer, et de ce que je me souviens c'était un des trucs que FF faisait (sqlite3, ce me semble).
En revanche, pour le côté coup de gueule anti-toolkit… D'une part, je te rejoins, d'autre part je suis pas d'accord.
Les toolkits se sont construits à une époque ou ils étaient nécessaires car tout restait à faire, surtout en C++ qui est un langage (qui me semble) jeune, ayant trop peu d'outils en standard (d'où l'émergence de boost et Qt je dirais).
Donc, ces frameworks, même s'ils subissent les erreurs de leur passé, ont joué, et jouent toujours, un rôle utile, pour créer des logiciels utilisables autant sous windows que d'autres OS. Sans eux, je n'aurais jamais franchi le pas, parce que j'aurai dû découvrir à 100% mon environnement libre, plutôt que de le faire progressivement.
En revanche, je dois admettre que quand j'utilise ces frameworks, je fais mon maximum à utiliser des fonctionnalités standard au maximum: je bannis les XXString, notamment. Et quand c'est possible, j'ai une préférence pour boost, qui est un ensemble de librairies faiblement couplées les unes aux autres.
En gros, je pense que ces frameworks ont eus à trouver des workaround à un langage (C++) trop restreint suffisamment vite pour ne pas être freiné par des normes qui mettent 12 ans à naître (et je n'ai pas parlé d'implémentation).
Mais quand on peut utiliser les normes, je pense qu'il vaut mieux oublier les fonctionnalités équivalentes du framework. Une des raisons majeures pour lesquelles je n'aime pas Qt par exemple, c'est la modification de la chaîne de compilation. Mais je dois admettre qu'un soft Qt est portable et bénéficie de perf correctes… tant qu'il ne s'agit pas d'un truc KDE, qui impose de télécharger VLC-nox pour un émulateur de terminal…
Le problème, ce ne sont pas les frameworks, mais les environnement de bureau qui n'arrivent pas à faire des choses modulaire. Ce n'est pas du tout la même chose. (j'aimerai qu'on m'explique pourquoi un terminal doit installer un module son, qui lui-même dépend de vlc, le tout impliquant finalement d'installer phonon, dépendant de… je parle de Qt, mais gnome est pareil sur ce point)
J'ai dis le problème? En fait, non, c'est la conséquence. Le problème, c'est que l'on veut tout faire à moindre effort. Ce qui inclue l'effort de moindre conception. Ce qui génère un couplage fort d'éléments qui n'ont pas une utilité vitale (sérieux… coupler vlc et un terminal…)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.