Le retour du Troll (WebKit Vs KHTML)

• [+] [^]Re: Le retour du Troll (WebKit Vs KHTML)

  Posté par Perthmâd (Jabber id, page perso, ) le 07/05/2008 à 15:10. (lien). Évalué à -2.

  Tu as oublié :
  
  6. Gecko rulaise ! Tout le monde rejoint la Mozilla Corp. !

  • [^]Re: Le retour du Troll (WebKit Vs KHTML)

    Posté par GeneralZod () le 07/05/2008 à 15:16. (lien). Évalué à 4.

    Pas tant que ça, du moins l'API pour embarquer Gecko s*cks grave.
    Du moins, la décision d'Epiphany de passer à WebKit a fait réfléchir certaines personnes à la MoCo.
    Voici le résultat du brainstorming:
    http://www.0xdeadbeef.com/weblog/?p=359
    
    Prochain brainstorming demain et après-demain.
    
    PS: mais tu as raison Gecko rules et il roulera encore mieux à l'avenir \o/

    • [+] [^]Re: Le retour du Troll (WebKit Vs KHTML)

      Posté par IsNotGood () le 07/05/2008 à 15:45. (lien). Évalué à -4.

      > l'API pour embarquer Gecko s*cks grave.
      
      Mouaif.
      Webkit est si génial qu'il ne sera peut-être pas encore intégré à Epiphany pour la prochaine version de Gnome...

      • [^]Re: Le retour du Troll (WebKit Vs KHTML)

        Posté par Julien () le 07/05/2008 à 15:58. (lien). Évalué à 1.

        troll spoted

        • [^]Re: Le retour du Troll (WebKit Vs KHTML)

          Posté par IsNotGood () le 07/05/2008 à 16:27. (lien). Évalué à 3.

          Non, c'est vrai.
          J'ai oublié les détails, mais il y a des problèmes avec les cookies, https, etc.
          Ça ne remet pas en cause Webkit, ça montre qu'il reste du boulot à Webkit.

          • [^]Re: Le retour du Troll (WebKit Vs KHTML)

            Posté par Julien () le 07/05/2008 à 16:31. (lien). Évalué à 2.

            C'est peut-être vrai, mais dire ça comme ça, sans expliquer plus, ça reste du lancer de troll pas super subtil.
            
            Si je dis "chez moi, Emacs est inutilisable alors que vim marche nikel" ça peut être vrai, ça n'en est pas moins un lancer de troll.

            [^]Re: Le retour du Troll (WebKit Vs KHTML)

            Posté par TeXitoi (Jabber id, page perso, ) le 07/05/2008 à 16:38. (lien). Évalué à 8.

            Il me semble que c'est pas globalement Webkit qui pose problème, mais webkit-gtk qui n'est pas encore vraiment fini. Le problème est donc plutôt que libwebkit-gtk est encore en stade alpha plutôt que "n'est pas génial", sous entendu possède des problèmes de conception, comme c'est le cas pour Gecko.

            • [^]Re: Le retour du Troll (WebKit Vs KHTML)

              Posté par alexissoft (Jabber id, page perso, ) le 09/05/2008 à 13:51. (lien). Évalué à 10.

              Ils auraient du utiliser Qt.

  [^]Re: Le retour du Troll (WebKit Vs KHTML)

  Posté par dguihal () le 07/05/2008 à 15:12. (lien). Évalué à 7.

  6. Obiwan Kenobi
  
  pour moi la réponse est un mélange de 1 et de 5
  
  Sinon QT 4.4 s'annonce comme du tout bon et la possibilité d'intégrer des widgets dans un QGraphicsView énorme

  [^]Re: Le retour du Troll (WebKit Vs KHTML)

  Posté par Julien () le 07/05/2008 à 15:28. (lien). Évalué à 2.

  7. Webkit sera utilisé dans certaines parties de KDE (plasma, ...) et KHTML dans Konqueror
  
  Sinon, un GSOC pour la solution 2 est en cours (kpart webkit)

  • [^]Re: Le retour du Troll (WebKit Vs KHTML)

    Posté par GeneralZod () le 07/05/2008 à 15:40. (lien). Évalué à 3.

    Si c'est vraiment la solution 7, ça risque de devenir assez lourdingue.
    La solution du Kpart serait plus judicieuse (aux distributions/utilisateurs ensuite de choisir le composant par défaut).

    • [^]Re: Le retour du Troll (WebKit Vs KHTML)

      Posté par Julien () le 07/05/2008 à 16:13. (lien). Évalué à 1.

      Qu'est-ce que tu entends par lourdingue ?
      
      Sinon, concernant la kpart, c'est effectivement la solution qui semble la plus adaptée pour le long terme. Mais soyons réaliste, elle signifie certainement la mort de la kpart KHTML et de KHTML avec elle à terme. Les discussions quant à l'acceptation de ce GSOC ont donc été assez houleuses sur la ML de KDE.
      
      Sinon, j'avais déjà écrit ici https://linuxfr.org/2008/04/02/23928.html#919463 un commentaire concernant ce qui me semble être les arguments des uns et des autres à ce sujet.

      • [^]Re: Le retour du Troll (WebKit Vs KHTML)

        Posté par GeneralZod () le 07/05/2008 à 16:33. (lien). Évalué à 6.

        Avoir deux moteurs de rendu là ou un seul suffirait c'est ce qui est lourdingue.
        
        > Elle signifie certainement la mort de la kpart KHTML et de KHTML
        C'est la dure loi de l'évolution, l'équipe actuelle a fait du bon boulot, un boulot qui est perpétué dans WebKit.
        WebKit a un développement plus dynamique que KHTML, la plupart des contributeurs clés de KHTML travaillent sur WebKit, il accumule plus de part de marchés que KHTML (adopté dans Safari, bientôt epiphany, AIR, Qt4.4 et bon nombre de téléphones). Les raisons pour lesquelles, KDE a pu être méfiante vis à vis de WebKit n'ont plus lieu d'être, une vraie communauté s'est constitué autour de WebKit.
        Si demain, Apple fermait ses développements -ce qu'ils ne feront probablement pas, je parie que dans l'heure, le travail recommencerait ailleurs.

        • [^]Re: Le retour du Troll (WebKit Vs KHTML)

          Posté par Julien () le 07/05/2008 à 16:40. (lien). Évalué à 2.

          Je ne comprend toujours pas ce que ça a de lourdingue ...
          
          Certe, dans l'idéal, il n'y a qu'un moteur utilisé partout, pour ne pas diviser les efforts des développeurs (mais on sait que c'est un argument fallacieux) et pour limiter la consomation de mémoire (mais ce n'est vraiment pas un gros problème pour l'utilisateur vu la taille des HDs et de la RAM sur les machines actuelles) ...
          
          Mais cet idéal n'existe nulle part. Sur toutes les machines il y a plusieurs moteurs de regexp, plusieurs parseurs XML, plusieurs bibliothèques de widgets ... Bref, des doublons.
          
          Donc ma question reste, quel problème ça pose, et à qui ?

          • [^]Re: Le retour du Troll (WebKit Vs KHTML)

            Posté par GeneralZod () le 07/05/2008 à 16:52. (lien). Évalué à 8.

            > il y a plusieurs moteurs de regexp, plusieurs parseurs XML, plusieurs bibliothèques de widgets
            
            On parle de KDE c'est à dire un environnement de travail intégré et cohérent, fournir deux moteurs de rendu c'est une aberration. Du moins, KDE doit se fixer l'objectif de pouvoir fournir un seul moteur par défaut quitte à permettre aux utilisateur de choisir lequel que ce soit au niveau du bureau ou par applications.
            
            ça veut dire qu'au fur et à mesure que les deux branches vont diverger, tu n'auras plus le même rendu entre Konqueror et Plasma, les correctifs de bogues ne sont pas appliqués simultanément, ça rapidement sera le boxon.
            
            
            > Donc ma question reste, quel problème ça pose, et à qui ?
            Aux développeurs web (qui devront supporter 2 moteurs supplémentaires au lieu d'un), aux utilisateurs de machines relativement peu puissante, aux développeurs qui font les frais d'une gueguerre stupide et insidieuse.

            • [^]Re: Le retour du Troll (WebKit Vs KHTML)

              Posté par Julien () le 07/05/2008 à 18:05. (lien). Évalué à 1.

              MMmouais, je pense qu'on est pas sur la même longueur d'onde et qu'on ne tombera de toute façon pas d'accord. De mon côté, il me semble vraiment qu'il s'agit d'un problème d'une importance assez faible. Il y en a bien d'autres qui méritent qu'on s'y attelle avant de mon point de vue.
              
              Et pour "développeurs web (qui devront supporter 2 moteurs supplémentaires au lieu d'un)" c'est le cas tant que KHTML existe, même si KDE n'utilise pas webkit.
              
              Pour le "aux utilisateurs de machines relativement peu puissante" Il faut se rendre compte qu'1Mo utilisé en RAM grand max, ça reste bon marché et que dès que tu charges quelques pages Web, ce sont ces données qui prennent de la place, pas le code lui même.
              
              Et pour le "aux développeurs qui font les frais d'une gueguerre stupide et insidieuse." J'ai pas compris

              [^]Re: Le retour du Troll (WebKit Vs KHTML)

              Posté par Julien () le 07/05/2008 à 18:12. (lien). Évalué à 2.

              P.S. autre argument auquel j'ai oublié de répondre :
              
              "au fur et à mesure que les deux branches vont diverger, tu n'auras plus le même rendu entre Konqueror et Plasma, les correctifs de bogues ne sont pas appliqués simultanément, ça rapidement sera le boxon."
              
              C'est déjà le cas, webkit a été forké il y a sufisemment longtemps pour que les corrections de bugs et autre ne puissent généralement pas être appliqués à la fois à KHTML et webkit.
              
              Quant au problème des rendus différents, il existe normalement des normes à ce sujet. Ceci dit, nous savons tous qu'elles ne sont pas appliquées parfaitement par tous les navigateurs. Et à nouveau c'est le cas, webkit et KHTML ont été forkés il y a sufisemment longtemps pour que les bugs de rendus soient différents entre les deux moteurs.
              
              Bref, j'ai l'impression que tes arguments (hormis celui concernant la consomation mémoire qui me semble mineur) penchent plus vers l'existance d'un seul moteur que vers l'utilisation d'un seul moteur par KDE. Est-ce que tu considère aussi que Gecko devrait disparaître au profit de webkit ou est-ce que je t'ai mal compris ?

              [^]Re: Le retour du Troll (WebKit Vs KHTML)

              Posté par Yusei (page perso, ) le 08/05/2008 à 12:40. (lien). Évalué à 6.

              Pour les développeurs web, avoir de nombreux moteurs de rendu à gérer est une bonne chose. S'il y en a deux ou trois, ça veut dire qu'il faut gérer les subtiles différences entre eux, mais s'il y en a douze, ça veut dire qu'on ne peut plus travailler comme ça, et qu'on est obligé de coder "pour les standards".
              
              Un développeur web ne peut pas dire "je code pour les standards, si IE ne fait pas du bon rendu, c'est son affaire", mais c'est dû à la supprématie d'IE. Plus le marché des moteurs de rendu est compétitif et plus les standards vont s'imposer.
              
              Par contre, je suis d'accord que KDE ne devrait pas avoir à gérer deux moteurs différents ayant le même but, c'est une source de problèmes inutile. Avoir un moteur puissant et lourd pour le web ainsi qu'un moteur ultra-léger mais simpliste pour afficher la documentation et les emails, par exemple, serait justifiable, mais avoir deux moteurs avec le même objectif...

              • [^]Re: Le retour du Troll (WebKit Vs KHTML)

                Posté par Gof (Jabber id, page perso, ) le 08/05/2008 à 13:00. (lien). Évalué à 2.

                >Par contre, je suis d'accord que KDE ne devrait pas avoir à gérer deux moteurs différents
                
                KDE ne gère que un moteur: KHTML
                (et celui-ci est légé pour afficher la documentation et les emails... et aussi le web :-) )

                --
                :-D !!!NOUVEAU!!!

              [^]Re: Le retour du Troll (WebKit Vs KHTML)

              Posté par Gof (Jabber id, page perso, ) le 08/05/2008 à 13:06. (lien). Évalué à 2.

              Quand webkit ou khtml est inclus dans une application (par exemple Plasma ou Kopete), ce ne sont pas les « développeurs web » qui font le html, mais les développeur ou les designer de l'application. Et il ne doivent « supporter » que le moteur de l'application.
              
              Par exemeple, les thèmes de Kopete sont en HTML, mais utilisent des fonctionalités propres à KHTML car seul ce moteur sera utiliser pour faire du rendu.

              --
              :-D !!!NOUVEAU!!!

            [^]Re: Le retour du Troll (WebKit Vs KHTML)

            Posté par Christophe Merlet (page perso, ) le 07/05/2008 à 16:59. (lien). Évalué à 10.

            > pour limiter la consomation de mémoire (mais ce n'est vraiment pas un gros problème pour l'utilisateur vu la taille des HDs et de la RAM sur les machines actuelles) ...
            
            Je suis désolé, mais je ne m'achete pas un nouvelle ordinateur avec chaque nouvelle sortie de distribution Linux.
            
            En entreprise c'est Idem, Le parc est énormément composé de machine n'ayant que 256 Mo de RAM (si en plus elle n'est pas partagé avec la mémoire vidéo).
            Et 256 Mo de RAM c'est vraiment limite inutilisable avec une distribution Linux moderne.
            
            Alors NON, je suis contre cette argument qui consiste à dire qu'on peut coder comme des porcs, ne faire attention a rien car on veut se convaincre que la puissance des machines compense !!

            • [^]Re: Le retour du Troll (WebKit Vs KHTML)

              Posté par Julien () le 07/05/2008 à 18:29. (lien). Évalué à 5.

              Oui, tu as raison, je me suis mal exprimé et je dis des bêtises du coup.
              
              Le vrai argument ici, c'est que dans ce cas, l'espace utilisé par le code est négligeable par rapport à celui utilisé par les donnés.
              Je n'ai pas de chiffre sous les yeux, mais je ne serais pas étonné que l'espace utilisé par le code de KHTML en mémoire soit inférieur d'au moins un ordre de grandeur à ce qui est utilisé par ses donnés (variables, notamment pour la représentation de la page en mémoire, l'exécution du JS, les images ...)
              
              Bref, selon la bonne vieille règle du 80 / 20, il vaut mieux s'attarder sur les 20% d'efforts qui amélioreront les perfs de 80% que l'inverse.
              Ces 20% concernent à mon avis l'utilisation des bonnes structures de données (voir par exemple ce papier http://www.oopsla.org/oopsla2007/index.php?page=sub/&id=(...) ). Si tu as des entiers que tu stocke dans un int[] ou dans un map<int,int>, tu peux avoir un facteur 10 entre l'occupation mémoire de l'un ou de l'autre.

              [^]Re: Le retour du Troll (WebKit Vs KHTML)

              Posté par FreeB5D () le 10/05/2008 à 19:51. (lien). Évalué à 0.

              Il m'est déjà arrivé de ne consommer que 230 Mo de RAM avec E17, qui est un environnement de bureau moderne, et Fx (avec un certain nombre d'onglets), qui est un navigateur moderne, et je faisais tourner sans problème Zenwalk (Xfce) sous 64 Mo de RAM . Donc 256 Mo de RAM ça suffit si on peut renoncer à un KDE/GNOME pour prendre Xfce ou E17 .

              • [^]Re: Le retour du Troll (WebKit Vs KHTML)

                Posté par IsNotGood () le 10/05/2008 à 20:29. (lien). Évalué à 2.

                > Donc 256 Mo de RAM ça suffit si on peut renoncer à un KDE/GNOME pour prendre Xfce ou E17 .
                
                Ça passe sous Gnome. Il n'y a que de légère optimisation a faire. Par exemple je n'utilise pas Nautilus, donc il n'est pas lancé.
                Je suis largement sous les 230 Mo de RAM...

            [^]Re: Le retour du Troll (WebKit Vs KHTML)

            Posté par vladislav askiparek () le 07/05/2008 à 19:28. (lien). Évalué à 0.

            ...limiter la consommation de mémoire...
            
            heu, tu parles de Firefox?
            
            ---->[ ]
            
            M'enfous, il fait très beau dehors.