KDE doit-il abandonner KHTML pour Webcore ?

Posté par . Modéré par Amaury.
Tags :
0
13
mai
2005
KDE
Dans un e-mail au mainteneur de moteur de rendu KHTML, le développeur principal du service navigateur d'Apple suggère l'abandon du code de KHTML ou la branche KHTML au bénéfice de la branche d'Apple appelée WebCore. Cette proposition a provoqué de vives réactions de la part des développeurs de KDE (KHTML fait partie du projet KDE) et s'est trouvée être l'occasion d'un bilan des deux ans de collaboration entre KHTML et Apple.

L'affaire fait suite au passage de l'Acid2 Standards-Compliant Test (test de compatibilité avec les standard Web extrêmement exigeant) par Safari. Il y a deux ans, Apple annonçait avoir choisi le moteur de rendu KHTML, issu du projet KDE, comme moteur de rendu pour son navigateur web destiné à supplanter Internet Explorer de Microsoft sur les systèmes Mac ; à l'époque, l'équipe de KHTML se réjouissait de ce choix et Apple s'érigeait en champion de la collaboration avec les développeurs open source.

Deux ans après, le constat est plutôt amer pour les développeurs de KHTML. La collaboration avec Apple s'est faite à sens unique et les deux projets KHTML et Webcore diffèrent tellement que les patches qui ont permis le passage de l'Acid test sont inapplicables aux sources de KHTML. Pour mettre fin aux critiques à son encontre, Apple n'a rien trouvé de mieux que de conseiller aux développeurs de KDE de migrer vers Webcore.

Cette dernière réaction semble être la goutte d'eau qui a fait déborder le vase. Les développeurs de KDE dressent un bilan très négatif de la « collaboration » avec Apple. Ils estiment n'avoir eu aucun poids dans le développement de Webcore, ce dernier s'effectuant essentiellement en interne et sans aucune concertation avec l'équipe de KHTML, l'accès aux source de la branches de développement restant malaisé. La plupart des développeurs de KHTML sont en total désaccord avec l'orientation prise par Webcore (patches rapides et inélégants) et ne souhaitent donc pas intégrer ce code à KHTML.

Le mainteneur de KHTML semble résigné et conclut par :
« Aussi longtemps qu'ils ont eu besoin de nous, ils nous ont utilisés, mais dès qu'ils ont acquis une base de connaissances suffisante, ils n'avaient plus de raison de nous envoyer des compte-rendus et des patches » et « À un moment ils ont décidé que la collaboration était devenue une perte de temps, et ils ont tout simplement cessé de communiquer... Il y a eu un espoir qu'ils contribuent à KHTML mais cela n'est jamais arrivé. »

Est-ce la preuve de l'incompatibilité entre un mode de développement trop éloigné du modèle Open Source (reproche déjà fait dans une moindre mesure à l'encontre de la Mozilla Foundation) ? Une mauvaise gestion de la collaboration par Apple, ou de trop grandes attentes de la part de l'équipe de KHTML ?

Aller plus loin

  • # Ou pour Gecko ?

    Posté par (page perso) . Évalué à 10.

    Zack Rusin termine l'intégration de Mozilla Firefox dans KDE
    http://www.mozillazine-fr.org/archive.phtml?article=6419(...)

    Le projet KDE porte Mozilla et ajoute le support dans les applications
    http://www.mozillazine-fr.org/archive.phtml?article=5263(...)
    • [^] # Re: Ou pour Gecko ?

      Posté par (page perso) . Évalué à 9.

      Ce serait quand même dommage de laisser tomber un moteur de rendu parfaitement fonctionnel, non?
      D'autant qu'avec l'évolution actuelle de la fondation mozilla, avoir une alternative libre à Gecko ne me paraît pas de trop...
      • [^] # Re: Ou pour Gecko ?

        Posté par . Évalué à 1.

        faut arrêter le troll sur la MoFo là
        qu'on approuve pas leur politique de marque OK, je la partage pas non plus mais Gecko est et restera libre, rien n'empêche d'utiliser Gecko dans KDE
        oui, dommage de laisser tomber khtml qui marche, mais c'est pas encore plus dommage de diviser les efforts du libre dans deux projets à finalité identique ? (ce qui est un vieux débat...)
        • [^] # Re: Ou pour Gecko ?

          Posté par . Évalué à 3.

          D'un point de vue utilisateur, à cet instant, ce n'est pas plus mal d'avoir 2 projets distincts :
          J'ai eu le problème d'un site avec du JavaScript mal codé qui se comportait mal avec Firefox (impossible de passer à la page suivante car un test était systématiquement faux). A priori, Konqueror doit être plus perméable (souple) au niveau de l'interprétation du JavaScript et Konqueror m'a permis de remplir le formulaire sans avoir à rebooter sous Windows pour utiliser IE. Au final, l'utilisation des 2 navigateurs dans leur état actuel a été un plus.
          • [^] # Re: Ou pour Gecko ?

            Posté par . Évalué à 0.

            Certes
            Mais avec un moteur unique qui gererait tout tu n'aurais même pas à changer de browser ;-)
            Plus sérieusement, cette vision est assez limitée: elle ne vaut que si tu es sous KDE et que tu utilises comme browser principal un autre browser que konqueror (genre ff, donc un truc GTK vu que XUL est rendu par GTK sous X11, arrêtez moi si ça a changé). Quelqu'un sous Gnome va pas installer konqueror et donc les 3/4 de KDE juste pour avoir khtml sous la main :-/ Donc au final ça ne lui sert à rien. Alors que des efforts conjugués aurais peut-être (you may say i'm a dreamer...) permis d'avoir un moteur unique meilleur que Gecko et khtml plus vite et avec une rapidité encore meilleure
  • # Licences

    Posté par (page perso) . Évalué à 10.

    La licence de KHTML est la LGPL qui permet à un tiers de faire un logiciel propriétaire avec du code LGPL...
    C'est qu'une vague histoire de licences... la morale de l'histoire pourrait etre "Dans l'avenir choisi bien ta licence"

    C'est ni plus ni moins qu'un Fork bien ficellé...

    .
    • [^] # Re: Licences

      Posté par (page perso) . Évalué à 3.

      au passage je vais citer fr.wikipedia.com


      KHTML est le nom du moteur de rendu HTML utilisé par le projet KDE.
      Il est écrit en C++ et disponible sous licence LGPL.
      *************************************************
      La différence avec la GPL est que la LGPL permet de lier un programme tiers non GPL à une bibliothèque LGPL, sans pour autant révoquer la licence. Ainsi, il devient possible à un programmeur désireux de faire un logiciel propriétaire, d'utiliser certains outils du libre (ex: la bibliothèque graphique GTK).
      • [^] # Re: Licences

        Posté par (page perso) . Évalué à -8.

        J'en viens à me demander si je vais pouvoir un jour aller pisser sans citer wikignegnia...
    • [^] # Re: Licences

      Posté par (page perso) . Évalué à 10.

      Bien sur, mais Apple aurait du prévenir les gens de khtml des le début et pas leur faire miroiter une pseudo collaboration!

      De plus, webcore est lié au technologie MacOSX, contient de l'objC donc reutiliser webcore dans Kde reviendrait à refaire un nouveau fork. Donc, vu que khtml a continué à évoluer depuis le fork de Apple, il n'y aucune raison de passer à webcore, ca serait une perte de temps.
      • [^] # Re: Licences

        Posté par (page perso) . Évalué à 10.

        Aller, un petit espoir quand meme:

        http://www.kdedevelopers.org/node/view/1046(...)

        Esperons que cela aboutisse vraiment à une meilleur collaboration entre les deux projets.
        • [^] # Pas de dispute

          Posté par (page perso) . Évalué à 7.

          C'est le blog de Carewolf.
          Je l'ai recopié à quelques lignes d'ici. En voilà l'essentiel: après une discussion sur IRC, il y a une opportunité de travailler ensemble: d'un côté on bosse sur le code pour KDE4, de l'autre Apple vient de finir Tiger et prépare la suite. Il faut juste trouver un mode de coopération.


          Hyatt and Maciej joined us on IRC yesterday, and we had some really good discussions. I might as well also admit that Maciejs comment was true (but out of context). Please notice that that implies we are discussing solutions and a common future. The idea of a common source tree is pretty much abandoned as we have very different goals and requirements, but we are discussing improved cooperation. With Apple just having released Tiger and us preparing for KDE4 we have a unique opportunity for bringing our source trees closer again.

          Since Apple is being a nice guy for the time being, I will let them announce how things will improve once we have a solution, but please, no more"vs." stories for the time being, we are working on solving it.

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: Licences

      Posté par . Évalué à 10.

      Pas totalement d'accord: Apple respecte la lettre de la LGPL et publie toutes les modifications apportées, KHTML pourrait être en GPL, cela ne changerait rien!

      Par contre Apple ne respecte pas l'esprit GPL/LGPL en faisant tres peu d'effort pour intégrer leurs modifications dans le projet originel, bref un fork comme tu dis.

      Certes les GPL/LGPL apportent la liberté de forker, liberté tres importantes et utile si le développeur original ne bosse plus dessus ou si on est en désaccord avec lui, mais forker pour forker comme Apple a fait, c'est assez méprisable..

      Bah, Apple a fait souvent des bétises de ce type: un exemple au lieu d'utiliser OpenGL comme librairie graphique, ils ont utilisé leur propre API 3D, que personne n'a utilisé bien sûr: ils n'ont pas le pouvoir de Microsoft!
      Résultat, ils ont du l'abandonner, en la remplaçant (finalement) par OpenGL, OpenGL qui entre temps s'est bien affaibli..
      Si Apple avait utilisé OpenGL dès le départ, il est envisageable qu'OpenGL soit beaucoup plus utilisé actuellement [ bon ok, vous me direz avec des si.., c'est juste un exemple d'une des c*** d'Apple].

      La je pense qu'Apple sous-estime le besoin de coopérer sainement avec des developpeurs du libres: apres un coup comme ça, je pense qu'il y a assez peu de developpeur de KDE qui seraient interressé par porter KOffice sur MacOSX, par exemple..
      • [^] # Re: Licences

        Posté par . Évalué à 10.

        Par contre Apple ne respecte pas l'esprit GPL/LGPL en faisant tres peu d'effort pour intégrer leurs modifications dans le projet originel, bref un fork comme tu dis.

        Sans vouloir trouver des excuses à Apple, il se trouve qu'il est généralement difficile de faire collaborer des équipes de devs qui travaillent sur leur temps libre (et n'ont pas d'obligation de résultat) et des gens qui bossent dessus à temps plein et doivent sortir du produit au bout.
        J'en veux pour preuve la quantité de patchs non appliqués par manque de temps dans le projet MPlayer: les contributions extérieures ne sont pas toujours dans la droite ligne du projet, et ne plaisent pas toujours à l'équipe de dévelloppement, tels qu'elles sont implémentées.

        Par exemple, le projet Unichrome, qui ajoute le support des puces graphiques VIA existe depuis pas mal de temps, et a été plusieurs fois rejetté parceque le patch touchait à beaucoup de choses à la fois, certaines de ces modifications étant par ailleurs inutiles.

        Si on regarde du côté de GCC, Apple a aussi sa version de GCC qui fonctionne diablement mieux pour générer du code Altivec que le GCC "normal". Or, toutes ces modifications ne se sont pas non plus retrouvées dans le "vrai" GCC pour les même raisons exposées plus haut.

        Bref, Apple ne respecte pas tellement l'idéologie, mais on ne peut pas dire non plus que ça soit évident de contenter tout le monde

        La je pense qu'Apple sous-estime le besoin de coopérer sainement avec des developpeurs du libres

        J'aurais été curieux de voir ce qu'aurait donné une collaboration "à la Red Hat": ie: embaucher les gens du projet pour le faire avancer suivant sa volonté.
        Ca marche avec RedHat, mais c'est une entreprise d'inspiration libre depuis le début.
        Apple, c'est différent, ils ont toujours été très secret sur leur façon de fonctionner... bah, peut-être qu'il faut leur laisser un peu de temps... Un virage à 180°, ça se négocie par trop vite, sinon on se casse la gueule...
        • [^] # Re: Licences

          Posté par . Évalué à 7.

          Je n'ai pas suivit la collaboaration entre l'equipe d'Apple et l'equipe GCC. Donc je ne peux commenter sur ce qui a ete fait ou non, et donc encore moins juger. Mais pour ce que j'ai vu de ces contributions "exterieures" sur d'autres projets (comme une entreprise qui contribue a un soft libre), generalement les devs du LL decouvrent l'existence du developpement presque en meme temps que la fourniture du patch. Si l'entreprise avait contacte les devs plus tot, les devs auraient fournit des conseils sur ce qu'il faut faire et ne pas faire, qui contacter dans l'equipe et d'autre choses a laquele l'entreprise n'imagine pas.
      • [^] # Re: Licences

        Posté par . Évalué à 7.


        Pas totalement d'accord: Apple respecte la lettre de la LGPL et publie toutes les modifications apportées, KHTML pourrait être en GPL, cela ne changerait rien!


        Bah si justement, étant donné qu'ils intègrent KHTML à du code proprio (Safari), avec la GPL ils n'auraient pas pu l'utiliser. Tu va me dire qu'à ce moment là KHTML n'aurait pas été choisi et serait resté seul dans son coin, c'est vrai.
    • [^] # Re: Licences

      Posté par . Évalué à 4.

      > La licence de KHTML est la LGPL qui permet à un tiers de faire un logiciel propriétaire avec du code LGPL... C'est qu'une vague histoire de licences... la morale de l'histoire pourrait etre "Dans l'avenir choisi bien ta licence". C'est ni plus ni moins qu'un Fork bien ficellé...

      Ce n'est pas un problème de conformité vis à vis des licences, il s'agit d'un problème de "moralité" vis à vis des développeurs KHTML qui ont permi à Apple de faire WebCore.

      « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

  • # Deux 'tites coquilles, et une vraie question

    Posté par . Évalué à 5.

    Coquille #1 : Cette proposition [...] s'est trouvée être ...
    Coquille #2 : (2ème lien) programmeur principal_ (d'ailleurs, comment vous dites pour une femme qui programme? programmeuse, ça sonne bizzare, non?)

    Vraie question : KHTML est bien un projet libre. WebCore peut donc être considéré comme un fork, chose somme toute pas vraiment rare dans le monde des LL.
    Je comprends bien que c'est contraire à l'esprit du libre de pomper les connaissances des devs de KDE tant que Apple en avait besoin, et ensuite de ne faire aucun retour, mais bon, ce n'est pas non plus contraire à la licence! Et justement, grâce à ladite licence, les modifs et divers patches créés par l'équipe de WebCore sont libres eux aussi, et même s'ils ne sont pas directement implémentables dans le code de KHTML, au moins le code est diponible.

    Si ça avait été une collaboration du type OOo/StarOffice (même si la situation initiale n'est pas vraiment la même), ce serait vraiment scandaleux, mais dans le cas KHTML/WebCore, on parle bien d'équipes de devs distinctes, à l'opposé de Sun qui fournit des devs pour le projet OOo.

    Alors ok, c'est pas cool pour l'équipe de KHTML, surtout qu'ils font un travail super et que sur le coup, ils sont pas vraiment récompensés, et c'est vrai que Apple aurait pu se retenir de proposer l'adoption de WebCore, mais bon, y'a pas mort d'homme non plus...

    mes 0.02 euros

    "Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).

    • [^] # Re: Deux 'tites coquilles, et une vraie question

      Posté par . Évalué à 4.

      Et justement, grâce à ladite licence, les modifs et divers patches créés par l'équipe de WebCore sont libres eux aussi, et même s'ils ne sont pas directement implémentables dans le code de KHTML, au moins le code est diponible

      Ok, la prochaine fois, je me renseigne, KHTML est sous LGPL, donc c'est même pas gagné que l'accès aux sources de WebCore soit possible. Mais dans ce cas, les devs de KHTML peuvent encore moins se plaindre, comme dit plus haut, ils ont mal choisi la licence :-/

      "Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).

      • [^] # Re: Deux 'tites coquilles, et une vraie question

        Posté par . Évalué à 7.

        Euh, je crois qu'il y a une incompréhension de la LGPL. Le code de la librairie est protégé par la GPL, sauf que les appli qui ont juste un lien avec la lib peuvent être sous une autre licence. Maintenant, si le code de KHTML a été modifié et que le binaire est distribué, alors les sources sont forcément disponibles. L'accès aux sources du moteur de rendu dérivé de KHTML est donc possible sans aucune ambiguité.
      • [^] # Re: Deux 'tites coquilles, et une vraie question

        Posté par (page perso) . Évalué à 9.

        Si, les dév KHTML ont bien accès aux source de WebCore. Seulement Apple fournit tout le code d'un bloc et non la succession des patches qui ont été appliqués. Or le code est tellement gros que c'est une tâche titanesque de l'exploiter. Les dév KHTML ont bien demandé à avoir un découpage par patches, qui permettrait de voir quelles modifs ont été faites sur quels fichiers pour implémenter telle fonctionnalité ou corriger tel bug, mais en vain. Apple se plie à ses obligations liées à la LGPL mais n'y met absolument pas de bonne volonté, ce qui fait qu'il est très difficile et fastidieux de reprendre leurs modifications.
        • [^] # Re: Deux 'tites coquilles, et une vraie question

          Posté par (page perso) . Évalué à 3.

          >> Apple fournit tout le code d'un bloc et non la succession des patches qui ont été appliqués.

          Tiens une idée me vient (c'est pas tous les jours).
          Imaginons la situation suivante : je suis une méchante corporation multinationale et je veux profiter tranquillement du code libre qui est produit par ces hippies de communistes de hackers....comment faire pour les entuber ?
          Simple : je pompe du code GPL et je le trifouille à ma sauce pour en faire un logiciel que je vends très très cher. Quand on vient me demander de livrer le code source (obligation induite par la GPL) je fais la manoeuvre suivante : je fournis un seul _gros_ fichier txt sans indentation et sans sauts de lignes qui regroupe tous les modules et bibliothèques de mon logiciel.
          C'est comme si le source complet était aligné sur une seule ligne.
          Inutile de dire que ce fichier txt est, sinon complètement inutilisable, du moins _très_ difficilement exploitable par quiconque qui voudrait récupérer mes divers patchs au fil du temps.

          Moralité : j'ai pompé du code GPL pour sortir mon fork à moi et j'ai respecté la lettre de la GPL tout en empêchant quasiment toute réutilisation par des tiers de ma version.
        • [^] # Re: Deux 'tites coquilles, et une vraie question

          Posté par (page perso) . Évalué à 1.

          Je croyais que dans les licences GPL et LGPL, tu devais dire quand et par qui quoi avait été modifié. donc en gros, tu devrais pouvoir retrouver ce qui a été modifié simultanément et donc probablement dans un même but.
          C'est pas tout à fait la suite de patches, mais on n'en est pas très loin.
        • [^] # Re: Deux 'tites coquilles, et une vraie question

          Posté par (page perso) . Évalué à 4.

          Je ne sais pas d'où tu sors ces infos, mais les patches sont là :

          http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008042(...)

          et ont été annoncés sur kde-core-devel :

          http://lists.kde.org/?l=kde-core-devel&m=111470451721883&w=(...)

          Le problème est qu'ils sont pour la plupart impossibles à appliquer parce qu'utilisant des bouts d'ObjectiveC ou des librairies spécifiques à OS/X (voir la suite du thread sur kde-core-devel).
      • [^] # Re: Deux 'tites coquilles, et une vraie question

        Posté par . Évalué à 1.

        Et il y avait même pas besoin d'aller loin pour se renseigner, les sources sont dans le premier lien de la news...
        Rappelons que dans le cadre de la LGPL, il doit y avoir un accès aux sources, pour tout le monde - pas juste pour Tintin et Milou, à partir du moment ou les binaires de la version modifiée sont distribués.
  • # Démagogie

    Posté par (page perso) . Évalué à 10.

    Cette proposition d'Apple n'est rien d'autre que de la démagogie : "Abandonnez votre joujou puisque vous manquez de ressources pour le faire évoluer vous-mêmes, et prenez le nôtre, on vous l'offre. Laissez tomber cette base de code que vous connaissez bien, que vous maîtrisez, et prenez celui de WebCore, qui n'y ressemble plus du tout..." Ah oui, le portage de WebCore ne risque pas de se faire en deux coups de baguette magique, mais Apple pourra dire que ce sont les dév KDE qui y mettent de la mauvaise volonté, et tout le monde risque de les croire, tellement Apple avait réussi à faire croire que leur boulot sur WebCore allait rapidement faire progresser KHTML.

    Vu sur le blog d'un dév KHTML il y a peu : http://www.kdedevelopers.org/node/view/1006(...)
    In December 2004 I “ported” the CSS text-shadow property from WebCore. I put ported in quotes because the only thing ported was the code to parse the property. In the rendering Apple had created an extension to KWQ (their Qt) that used an OS X call to draw the shadow. This meant that to “port” it I had to write the shadow drawing myself.
    Résumé : pour certaines fonctionnalités, WebCore utilise les bibliothèques d'OSX, qui sont loin d'être libres. Porter WebCore nécessiterait donc de réécrire énormément de fonctionnalités fournies par ces biblio. Faire cette proposition alors qu'Apple sait que KHTML n'a actuellement que de faibles resources me fait vraiment penser à un gros foutage de gueule...
    • [^] # Re: Démagogie

      Posté par . Évalué à 2.

      Il n'y a rien de vraiment choquant dans le comportement d'Apple. Le seul truc, c'est une mésentente à la base sur l'avenir du projet. D'un fork amical, c'est devenu un fork inamical, mais bon, ça s'arrête là.

      De toutes manières, si l'équipe de KHTML ne veulent pas reprendre le code qu'on leur propose, c'est qu'ils estiment qu'il est moche. Par conséquent, WebCore va être un soft buggé, difficile à faire évoluer. Pas de quoi piquer une crise.

      C'est juste dommage pour les dev de KHTML qui ont perdu du temps dans cette "pseudo collaboration" ; maintenant, KHTML ne va pas bénéficier deu développement d'Apple, et vice versa. La communauté des gens capables de faire des rapports de bugs corrects et de proposer des patches est du côté de KHTML, donc WebCore va y perdre au moins autant que ce qu'ils avaient gagné. C'est une histoire de stratégie d'entreprise.

      Si par contre ce comportement est juste dû à quelques kékés qui n'ont rien compris au libre et qui plombent la stratégie d'Apple par flemme ou pour se faire mousser, ça va chauffer. Mais je ne crois pas qu'il s'agisse de ça.
      • [^] # Re: Démagogie

        Posté par (page perso) . Évalué à 6.

        Le problème c'est que Apple n'a jamais dit avoir fait un fork et son moteur s'identifie toujours comme KHTML en utilisant les propriétés CSS -khtml-....

        Ceci fait que de nombreuses personnes s'imaginent que Konqueror et Safari ont le même rendu et donc quand un truc marche sur Safari mais pas Konqueror les bugs-reports ressemblent à "TrucMuche work on Safari but not on Konqueror. How is it possible ? Please fix this quickly".
        Je comprend que ça fasse raler les développeurs KHTML car l'inverse est plus rare, les utilisateurs Konqueror étant plus au courant du fait que WebCore est un fork et non le même projet comme Apple semble le faire croire.

        Webcore est un fork sauvage de KHTML. Que les développeurs web le sachent et arrêtent de faire chier l'équipe KHTML avec Safari qui lave plus blanc. Apple a des moyens et l'équipe KHTML est restreinte et a peu de moyen. Les développeurs de KHTML étant en plus souvent développeurs sur d'autres parties de KDE.

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

        • [^] # Re: Démagogie

          Posté par (page perso) . Évalué à -1.

          > les bugs-reports ressemblent à "TrucMuche work on Safari but not
          > on Konqueror. How is it possible ? Please fix this quickly".

          kde n'a qu'à faire comme les autres ânes de la mozilla fondation et déposer la marque khtml, il parait que ça aide à ne plus avoir ce genre de bugreport

          [:kiki]
      • [^] # Re: Démagogie

        Posté par . Évalué à -1.

        En lisant ce post, je me demande si c'est pas plutôt :

        Utilisez WebCore plutot que KHTML pour que vous nous débuggiez gratis le code pourri qu'on a pondu.
    • [^] # Re: Démagogie

      Posté par (page perso) . Évalué à 1.

      Apple a intérêt à ce que les développeurs de KDE utilisent Webcore, comme ca Webcore continuera d'évoluer grâce a la communanuté. Ils ont pas compris qu'on peut pas dicter à la communauté du libre de suivre ses choix commerciaux.
  • # La situation semble se détendre entre les deux parties

    Posté par . Évalué à 9.

    http://www.kdedevelopers.org/node/view/1046(...)

    L'article de CNET fait dans le sensationnalisme ronflant en arrivant 2 semaines après la bataille (By Paul Festa : comment ça j'avais deviné l'auteur avant même de cliquer sur le lien ?)
  • # Mise a jour ...

    Posté par . Évalué à 3.

    merci de lire ce blog :
    http://www.kdedevelopers.org/node/view/1046

    la cooperation n'a pas encore totalement disparue apparemment

    Mik
  • # Un mars aussi ?

    Posté par . Évalué à 10.

    J'ai un peu l'impression qu'on se focalise sur apple qui DOIT contribuer à khtml. Des forks ou des projets qui se basent sur d'autres LL y'en a toute les semaines. Est ce que ces forks ont pour mission de macher le travail ? Non ! Si on maintient une branche séparée c'est bien par ce qu'on ne pouvait pas faire avec la version principale. À partir de là, laisser le libre accès à ses modifications me semble suffisant. Si les changements interessent l'autre équipe c'est à eux de fournir le travail pour intégrer.

    Par exemple quand Dillon à créé Dragonfly BSD personne chez FreeBSD n'a demandé que le boulot leur tombe dans le bec. Si FreeBSD veut des choses de Dragonfly bin ils remontent leurs manches et se débrouillent comme des grands pour que ca marche chez eux.

    Bien sur on peut rêver d'un monde idéal... Le monde réel c'est un ensemble de joueurs ou chacun essait de tirer au mieux son epingle du jeu. C'est un jeu d'influence, de buz, et de technique. La c'est apple donc c'est des méchants, mais au sein de tout projet c'est exactement la même chose à une échelle plus petite. Chacun s'arrange pour que ca aille dans la direction qui l'interesse.

    Pour finir si on veut pas que cela puisse se produire on fait du proprio/open source.
    • [^] # Re: Un mars aussi ?

      Posté par . Évalué à 10.

      entiérement d'accord !
      le procès fait à apple ici pourrait être fait à n'importe quelle équipe de développement ayant forké un soft

      c'est dingue quand même, quand une boite fait que du proprio, on le lui reproche, et à l'opposé quand elle s'investit un peu dans l'open source, elle est tout aussi critiquée.. mon avis perso est que ça décrédibilise le monde de l'open source, en le faisant passer pour pleurnicheur et éternel insatisfait, et ça c'est vraiment dommage :/
      • [^] # Re: Un mars aussi ?

        Posté par . Évalué à 1.

        Le problème, et il faudra le répéter encore souvent, c'est qu'il ne s'agit pas d'un fork propre, si c'était le cas, webcore ne s'identifierait pas comme étant khtml et les préfixes css de safari ne seraient pas les même que dans konqueror !

        Sinon, en effet, à part un perte de temps et de l'énervement, il n'y a pas de mal à faire un fork, mais alors il faut le faire jusqu'au bout !
        • [^] # Re: Un mars aussi ?

          Posté par (page perso) . Évalué à 2.

          Fork propre ou pas ... un fork reste frustrant pour une équipe de développement. Maintenant faut être un peu réaliste, on peut pas tout faire dans le pure respect de règle d'un "fork" ... pour autant qu'il y ai des règles.

          Apple par de son côté, KHTML reste sur leur position ... pas grave, je profite du meilleure des deux mondes.

          Je trouve qu'il y a quand même pas mal d'extrémisme dans ce procès Apple vs KHTML ...
          • [^] # Re: Un mars aussi ?

            Posté par . Évalué à -4.

            Moué, en même temps, Apple n'est pas un bleu et sait très bien ce qu'il fait (vous oubliez tous qu'Apple est roi du brevet et de l'inintéropérabilité).

            Apple par de son côté, KHTML reste sur leur position ... pas grave, je profite du meilleure des deux mondes.


            Qu'on ne dise pas qu'Apple contribue au libre dans ce cas, il y a une différence entre un fork libre et un fork commercial.
            Ce qui m'amène à penser qu'on peut malheureusement encore filouter une licence libre visiblement.

            Bref, Apple a été très malin sur ce coup, éspèrons juste que les devs libres se souviendront de l'intérêt de choisir judicieusement sa licence, cela semble être la seule morale de l'histoire. (j'suis peut-être limité cérébralement ^_^)

            [mode spéculation]
            Peut-être que la team de KHTML avait peur de passer pour extrêmiste en ne choisissant pas la très critiquée GPL qui est pourtant la véritable garante de notre code libre.
            [retour à la réalité]

            +


            nb: Dire qu'il y a peu je demandais des infos sur les contribs d'apple pour le libre (car ce ne sautait pas aux yeux), maintenant j'en ai pour mon argent :o)
  • # Le mieux à faire...

    Posté par . Évalué à 8.

    C'est que KDE continue son chemin avec KHTML...

    De toutes façons, il y a un plus grand nombre d'utilisateurs potentiels pour KDE que pour Apple, alors autant ne pas marcher dans un sentier jonché de pommes pourries.

    Et si chez apple ils veulent voir webcore sous linux, qu'ils le fassent eux-mêmes...
    • [^] # Re: Le mieux à faire...

      Posté par (page perso) . Évalué à 2.

      Surtout que je sais pas si il faut généralisé, mais les seuls maceux que je connais(info graphistes) sont passés sous firefox et semblent pas pres de changer! Je n'ai eu que des éloges de ce dernier!
      • [^] # Re: Le mieux à faire...

        Posté par . Évalué à -10.

        Vraiment n'importe quoi...moi les maceux que je conais sont tous informaticiens, commes les 5 directeurs de spécialités de master d'info de ma fac et moi-mêm....ah oui on est sous OS X maintenant t'es pas au courant??
        Les switchs Linux -> OS X sont bien plus nombreux qu'on ne le dit parmis les informaticiens fan de LL (même si les couches proprio de OSX font très mal à certain).
        • [^] # Re: Le mieux à faire...

          Posté par . Évalué à 3.

          En tout cas, ASpell n'a apparemment pas été porté sous MacOSX si on en juge par votre écriture de porc. À bon entendeur, Gruiiiiik ...

          « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

        • [^] # Re: Le mieux à faire...

          Posté par (page perso) . Évalué à 4.

          Quand je parlais de Firefox, je parlais bien sur de Firefox sous OS X, t'es au courant que c'est un logiciel multi plateforme?
          • [^] # Re: Le mieux à faire...

            Posté par (page perso) . Évalué à 0.

            Oui mais il n'est pas si bien intégré ...
            Ou est la jolie interface chromée ? C'est le dernier argument que j'i eu pour ne pas passer à Firefox (un autre c'est que Safari c'est bien et c'est déja installé).

            Et a mon avis, un thème ne change pas cela, l'interface chromée permet de déplacer la fenêtre n'importe où ou c'est chromé. Pas seulement dans la barre de titre.

            Aussi, il y a trop de boutons pour certains. A quoi sert le bouton Stop a coté du bouton Recharger. On ne peux pas stopper et recharger une page en même temps.

            Le gestionnaire de bookmarks de Safari est à l'interieur de la fenêtre, ce n'est pas une fenêtre séparée.

            On ne peux pas redimentionner la barre d'adresse et la barre google avec Firefox.

            Par contre, j'aprécie beaucoup FireFox (puisque je l'utilise), et je ne l'abandonnerais pas por Safari. Manue Adblock, WebDeveloper et des choses comme l'inspecteur DOM qui sont bien utiles.
            J'ai juste résumé des arguments qui pouvaient être utilisés.
            • [^] # Re: Le mieux à faire...

              Posté par (page perso) . Évalué à 2.

              A quoi sert le bouton Stop a coté du bouton Recharger. On ne peux pas stopper et recharger une page en même temps.

              Bien vu!
              A soumettre aux devs de Mozilla, Firefox, Konqueror, ...

              "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

              • [^] # Re: Le mieux à faire...

                Posté par (page perso) . Évalué à 1.

                Il y a une extension pour firefox qui le fait stopreload ou un truc du genre.
              • [^] # Re: Le mieux à faire...

                Posté par . Évalué à 2.

                Pas en même temps, non, mais tu peux choisir de stopper ou de recharger la page. Sinon au lieu de recharger tu proposes de stopper puis recharger ? Ou est-ce que c'est le bouton STOP qu'il faut supprimer ?
                • [^] # Re: Le mieux à faire...

                  Posté par (page perso) . Évalué à 3.

                  Ca pourrait être le même bouton qui change selon si la page est en train de se charger (=> stop) ou finie de charger (=> recharger).

                  Je suppose que c'est le cas sur Safari.
                • [^] # Re: Le mieux à faire...

                  Posté par (page perso) . Évalué à 2.

                  Si la page est deja en train de charger, je ne pense pas que l'utilisateur lambda est besoin de la recharger.

                  L'utilisateur avancé quant à lui appuiera sur stopper/recharger succesivement et rapidement ou utilisera le raccourci clavier (mais je ne vois toujours pas l'interet)
                  • [^] # Re: Le mieux à faire...

                    Posté par . Évalué à 3.

                    Si la page est deja en train de charger, je ne pense pas que l'utilisateur lambda est besoin de la recharger.

                    Désolé, mais non, il ne faut pas penser à ce dont l'utilisateur l'ambda a besoin, il faut lui demander...

                    Il arrive fréquemment que des pages ne terminent pas d'être transférées, mais le browser reste en attente. Avec un bouton reload, il est plus rapide et plus intuitif de faire redémarrer le téléchargement de la page qu'en devant faire un stop->reload. Avec un bouton à deux états (stop et reload), l'utilisateur peut se méprendre sur l'état du bouton et faire un stop d'une page en train de charger ou un reload d'une page chargée alors qu'il n'en a pas besoin, pour peu que l'état du bouton change pendant que l'utilisateur veuille utiliser son état précédent.
              • [^] # Re: Le mieux à faire...

                Posté par . Évalué à 5.

                A quoi sert le bouton Stop a coté du bouton Recharger. On ne peux pas stopper et recharger une page en même temps.

                Bien vu!
                A soumettre aux devs de Mozilla, Firefox, Konqueror, ...


                Non, mal vu. Un bouton qui change de fonction selon le contexte est une horreur ergonomique.
                • [^] # Re: Le mieux à faire...

                  Posté par . Évalué à 2.

                  Perso dans un cas comme ça ou deux fonctions sont à peu près l'opposé l'une de l'autre et mutuellement exclusives, je vois pas trop le problème.
                  Mais ceci dit, les HIG de Gnome par exemple sont d'accord avec toi. Enfin, c'est pas parfaitement explicite, mais est cité le cas des boutons Play et Pause dans les toolbars des lecteurs multimédia, qui est très similaire, et la recommandation est : « Do not change Play to Pause while the clip is playing. »
                  http://developer.gnome.org/projects/gup/hig/2.0/toolbars.html(...)

                  Une explication du pourquoi ?
                • [^] # Re: Le mieux à faire...

                  Posté par (page perso) . Évalué à 3.

                  L'utilisateur peut peut etre le considerer comme un interrupteur.

                  Le bouton de la lumiere change de fonction selon le contexte.

                  Lumière eteinte : Le bouton sert à allumer.
                  Lumière allumée : Le bouton sert à éteindre.
            • [^] # Re: Le mieux à faire...

              Posté par (page perso) . Évalué à 2.

              Aussi, il y a trop de boutons pour certains. A quoi sert le bouton Stop a coté du bouton Recharger. On ne peux pas stopper et recharger une page en même temps.


              C'est vrai je n'avais jamais fait attention.
              Quelqu'un voit une utilité à ce truc ?

              Par contre un truc aussi qui ne sert à rien je trouve c'est le bouton ->OK à coté de la barre d'adresse. Quand on tape une url, on la tape au clavier, je ne vois pas l'interet d'attraper la souris et de cliquer sur ->OK.
              • [^] # Re: Le mieux à faire...

                Posté par (page perso) . Évalué à 4.

                Détrompe toi...
                Beaucoup de gens ne savent pas quoi faire une fois l'URL tapée. C'est facilement compréhensible: pourquoi faire "entrée", où est la logique? aucune interface graphique ne montre de lien entre cette touches et les différentes versions des boutons "valider", "ok", "envoyer" etc.
                Quand je m'en sers devant des stagiaires, j'ai l'impression de leur révéler un nouveau raccourci clavier...

                Cela dit, s'il n'y avait pas de bouton "ok" sur IE, la plupart des utilisateurs finiraient par comprendre.

                "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

                • [^] # Re: Le mieux à faire...

                  Posté par . Évalué à 2.

                  Sous Konqueror la rééducation de l'utilisateur a déjà commencée, le bouton "valider" a la forme de la touche entrée, si avec ça l'utilisateur de voit pas le lien entre les deux.
              • [^] # Re: Le mieux à faire...

                Posté par . Évalué à 2.

                Des fois, l'adresse on la copie/colle a la souris.
              • [^] # Re: Le mieux à faire...

                Posté par . Évalué à 1.

                Justement, les barres d'outils de FF sont paramétrables aisément, et on peut virer cet inutile bouton [OK] dès qu'on a compris qu'[Entrée] suffisait amplement ! :)
            • [^] # Re: Le mieux à faire...

              Posté par . Évalué à 1.

              >> On ne peux pas redimentionner la barre d'adresse et la barre google avec Firefox.

              Si, grace à cette extension : http://extensions.geckozone.org/ResizeSearchBox/(...)
      • [^] # Re: Le mieux à faire...

        Posté par (page perso) . Évalué à 2.

        ah ? les maceux que je connais utilisent tous safari.
        Il est plus beau (il s'integre parfaitement au bureau osx alors qu'au mieux firefox melange brushed metal et pas brushed metal)
        Il est plus rapide
        Il supporte mieux les css

        Pour le premier point, il y a camino, mais franchement, la seule raison que j'y verrais c'est d'etre allergique au proprietaire, et c'est pas coherent avec l'utilisation d'osx.

        Sinon, il y a opera qui est pas mal : au niveau css, ca doit etre sensiblement equivalent, mais il a ses pubs, et il a des lenteurs dans l'interface.

        Donc vraiment, si c'est pour le plaisir d'utiliser un navigateur libre, je conseillerai shiirad (belle interface, utilise le meme moteur de rendu que safari)
        • [^] # Re: Le mieux à faire...

          Posté par (page perso) . Évalué à 2.

          On connais pas les mêmes "maqueux", tous ceux que je cotois utilisent Firefox :)

          Par contre je connais pas shiirad, je vais voir ca de ce pas : http://hmdt-web.net/shiira/index-e.html(...) ?

          Quand a khtml, ben oui il faut pas croire Apple (ni beaucoup de socétés) quand elles disent "on est gentil tout plein on va vous aider, vive le libre"
    • [^] # Re: Le mieux à faire...

      Posté par (page perso) . Évalué à 0.

      Ça dépend vraiment de ce que tu entends par « mieux ». Par exemple, moi je trouve que le mieux à faire c’est de passer à GNOME. Comme tous les navigateurs de qualité (Firefox, Galeon, Epiphany...) sont en GTK+, on économise en empreinte mémoire.
      • [^] # Re: Le mieux à faire...

        Posté par . Évalué à 5.

        Ma définition de "mieux" : garder son projet plutôt que de se retrouver à devoir courrir indéfiniment derrière Apple afin que ce dernier ne pompe encore des trucs sans fournir à la communauté quoique ce soit d'utilisable en retour.

        Pour le reste, je suis déjà sous gnome mais je ne compte pas faire de querelle de clocher entre gnome et kde. KDE est un projet formidable, Gnome aussi. L'important c'est que ces projets restent des projets servant à leur communauté et non à une entreprise extérieure s'amusant à déposer des peaux de bananes...
      • [^] # Re: Le mieux à faire...

        Posté par (page perso) . Évalué à 5.

        Trop gros, passera pas…

        Envoyé depuis mon PDP 11/70

    • [^] # Re: Le mieux à faire...

      Posté par . Évalué à 4.

      Et si chez apple ils veulent voir webcore sous linux, qu'ils le fassent eux-mêmes...

      Il est clair que ce n'est pas le but d'Apple. Je pense plutôt que cette proposition va dans le sens de leur conception de la "coopération" entre projets libres.

      Apple se gausse d'avoir réussi à passer l'Acid2, et dans un élan de bonté ils proposent aux développeurs de KHTML, qui n'est pas au même niveau sur ce point, de reprendre les fruits de leur boulot partiellement ou complètement. C'est à la fois de la pub et une volonté d'entraide telle qu'ils peuvent la concevoir. Que les dévs de KHTML acceptent ou pas, c'est une autre histoire, il auront sûrement de bonnes raisons de ne pas le faire mais reste à voir objectivement si ca peut être intéressant de partir sur une base webcore ? En dehors du strict respect des standards et de l'Acid2, où en sont respectivement les deux projets ?

      L'intérêt immédiat, si cette proposition aboutissait, serait la compatibilité qui redeviendrait bonne entre les moteurs WebCore (qui s'identifie, comme certains le soulignent, comme khtml) et khtml. Ce n'est pas anodin, comme avantage... Aussi bien konqueror que Safari sont promis à un bel avenir et il est dommage que les développeurs web ne puissent en tirer pleinement profit à cause de leurs différences pas clairement identifiables.

      Et puis, Apple aurait très bien pu ne rien proposer du tout...
      • [^] # Re: Le mieux à faire...

        Posté par . Évalué à 5.

        Et puis, Apple aurait très bien pu ne rien proposer du tout...

        Oui, proposer, c'est bien, mais il faut voir les conditions, les licences.

        Si tu proposes un sandwich aux saucisson pur porc à un rabbin, je ne pense pas qu'il voie ça comme de la générosité... et si tu sais pertinamment que les rabins ne mangent pas de porc, on ne peut pas te qualifier non-plus de généreux. (maintenant, certains dirons "il est con, ce rabin, un sandwich au saucisson pur porc, ça ne se refuse pas", mais là on entre dans un débat de principes)
        • [^] # Re: Le mieux à faire...

          Posté par (page perso) . Évalué à -2.

          Si ... ca se refuse lorsqu'on accepte pas de manger des animaux coupés en rondelles (des cadavres d'animaux, devrais-je dire)
  • # traque aux bugs

    Posté par (page perso) . Évalué à 10.

    Apple suggère l'abandon du code de KHTML ou la branche KHTML au bénéfice de la branche d'Apple appelée WebCore

    lire entre les lignes : on a besoin d'un plus grand nombre de gens pour chasser nos bugs, si vous remplacer KHTML par WebCode notre controle qualité sera amélioré.
    • [^] # Re: traque aux bugs

      Posté par . Évalué à 2.

      je te pertinenterai bien si tu n'étais déjà à +10... surtout qu'un des commentaires ci dessus explique que les patch fournis par apple étaient souvent gorets et refusés pour cela par les devs kde.

      un an de patch gorets, ça finit toujours par se payer.

      La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".

  • # Apple is near microsoft

    Posté par . Évalué à 5.

    Franchement, rien d'etonnant de la part d'apple, faudrais pas croire que c'est une societe autre que commerciale, type microsoft.

    Si apple avait eu le succés de microsoft, rien ne dis que nous ne detesterions pas tous Apple aujourd''hui. C'est pas loin d'être plus propriétaire que Microsoft par moment....
    • [^] # Re: Apple is near microsoft

      Posté par . Évalué à 4.

      Tu as raison. Imaginez vous que c'est Microsoft qui vend os x et que c'est Apple qui vend windows. Je suis sûr que beacoup de gens vont aimer Microsoft et détester Apple. Ceci veut dire qu'il ne faut pas simplement fonder notre oppinion uniquement sur la qualité technique d'un produit.

      Je suis content d'avoir choisi linux (une debian unstable) pour mon iBook G4. J'ai installé le dual boot, mais finalement je ne reboot presque plus sous os x. Je vais virer complètement os x quand j'aurais trouvé une solution wifi avec support wpa.
      Je ne suis pas un inconditionnel de logiciels libres, mais comme beaucoup de lecteurs de DLFP, j'essaie d'utiliser le maximum de logiciels libres.
    • [^] # Re: Apple is near microsoft but ...

      Posté par (page perso) . Évalué à 1.

      Un point important aussi chez apple: ils font tout pour les standards ...
      En fait, ils y on un interêt: ils sont minoritaires sur le marchés des ordinateurs personnels, alors ...
      Mais on a pas mal de trucs de chez eux, il me semble ... Par exemple Wifi, USB, FireWire ou ZeroConf (=rendezvous=bonjour)
      Peut être que certaines de ces technologies ne venaient pas de chez eux directement ... mais il les ont intégrés très en avence.

      Il me semble qu'on trouve encore beaucoup de PC sans pour firewire alors que c'est la norme chez Apple. C'est vrai, il n'y a pas beaucoup de périphériques compatibles (je n'en ai pas alors que j'ai un port FireWire), mais ca va venir.
      • [^] # Re: Apple is near microsoft but ...

        Posté par (page perso) . Évalué à 3.

        Et leur nouvelle balise "canvas" que les développeurs Mozilla sont aussi en train d'intégrer c'est standard ?
        Non.
        Si dans un an les sites pullulent avec ce truc on se retrouvera avec les mêmes merdes qu'à l'époque des "layer" de Netscape. Heureusement Safari n'ayant pas le monopole ça n'arrivera pas.

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

      • [^] # Re: Apple is near microsoft but ...

        Posté par . Évalué à 4.

        Il me semble qu'on trouve encore beaucoup de PC sans pour firewire alors que c'est la norme chez Apple...

        Il y a peut-être une explication très simple : la licence Firewire n'est pas gratuite (à la différence de celle de l'USB), elle est vendue – chère parraît-il – par Apple. Partant de là, il est logique que les fabricants de matèriel ne l'intègrent que sur des machines plustôt haut de gamme afin de ne pas plomber le prix des PC courants.
        Côté photo et vidéo, beaucoup de fabricants équipent aujourd'hui leurs camscope en USB2, seuls restent (généralement) en Firewire les appareils photo pro genre Canon EOS 1D/Ds ou Nilon D1/D2.
        De plus, lorsque le port Firewire est présent sur un portable, c'est souvent en version 4 broches (appelé iLink chez Sony) et donc ne permettant pas l'alimentation d'un périphérique tel qu'un disque (les petits qui tiennent dans la poche :o), à la différence de l'USB2.
        Dans ce contexte, l'intérêt du Firewire 400 devient donc de plus en plus faible, tout le monde n'a pas besoin d'une pile de LaCie pour archiver son boulot ou ses photos, vidéos, mp3… ce qui explique peut-être pourquoi les fabricants de PC ne forcent pas la main aux clients en vendant un port dont bien peu on besoin.
  • # Utilisation de Safari ?

    Posté par (page perso) . Évalué à 2.

    Il y a beaucoup de monde qui utilise Safari ?

    Je ne connais pas beaucoup de personnes sous Mac-OS, mais elles utilisent toute soit IE soit Firefox...
    • [^] # Re: Utilisation de Safari ?

      Posté par (page perso) . Évalué à 2.

      IE n'est plus maintenu sous OSX et d'ailleurs plus livré depuis la 10.3
      L'enjeux pour Apple n'est pas d'avoir "Le navigateur". Mais d'en proposer un par défaut. Les macquistes ont toujours choisie leur navigateur. Sous Mac OS 9 IE et Netscape étaient livrés par défaut. Le succés de FireFox sous Mac est bien moins surprennant que son succés sous windows

      Ceci dit Safari est un bon navigateur. Bien plus modèrne que IE
    • [^] # Re: Utilisation de Safari ?

      Posté par . Évalué à 3.

      Bah, je bosse dans une boite de pré-presse (50 personnes). Sans surprise, 90% de Mac OS X ici. Pratiquement tout le monde utilise Safari, quelques irréductibles de IE, une personne dois utiliser Firefox (pas moi, mais patapé). Je dois reconnaitre que le boulot fait par Apple est pas mal : le rendu de Safari (très proche de Gecko) est magnifique et très bien intégré au système.

      Je pense que là où Safari (et KHTML aussi d'ailleurs) enfonce FireFox (enfin Gecko), c'est en vitesse de rendu. Utilisez des div en "position: fixed" ou de la transparence PNG avec un "background-position: fixed" : c'est d'une lenteur exaspérante avec FireFox. Sur les G4 500 du parc, c'est très trés pénible, Safari en comparaison est 2 à 3 fois plus rapide.

      Et puis, j'attends encore le jour où Gecko cessera d'utiliser son système de widget "fait maison", qui est plus moche que Motif et Tk réuni (encore une raison de préférer KHTML ou Safari).
      • [^] # Re: Utilisation de Safari ?

        Posté par . Évalué à 1.

        Le boulot fait par Apple est pas mal


        Oula, avant que ça parte en troll .... j'aurais du préciser le plus gros du boulot à quand même été fait par l'équipe de KHTML.
      • [^] # Re: Utilisation de Safari ?

        Posté par (page perso) . Évalué à 7.

        Je te rejoins sur la vitesse d'affichage : j'ai créé une page avec plusieurs « background-position: fixed » sous Mozilla il y a un an, et je trouvais ça assez lent niveau scrolling (comme les autres pages qui utilisent ça).

        À l'époque, ça marchait pas bien sous Konqueror (sa faute ou la mienne, je sais plus), j'avais pas trop examiné le problème, mis au rayon du « Konqueror ne respecte pas encore assez bien les standards ».

        Récemment, j'ai refait un essai, j'ai été bluffé : ça scrolle très fluide sous Konqueror, Mozilla ressemble à une grosse brouette à roue carrée en comparaison !
        • [^] # Re: Utilisation de Safari ?

          Posté par (page perso) . Évalué à 4.

          > ça scrolle très fluide sous Konqueror, Mozilla ressemble à une grosse brouette à roue carrée en comparaison !

          Ah ben là, je ne peux qu'être d'accord, ça fait des lustres que je répète que Konqi est plus rapide lorsqu'on vient me vanter la vitesse de Faïrefosque. Mais jusqu'à pas si longtemps, je n'avais que mon impression subjective. Maintenant, il y a un monsieur qui a fait des tests (j'avais vu ça sur /. il y a quelques temps) et ça donne ceci [http://www.howtocreate.co.uk/browserSpeed.html#linspeed(...)].

          En resumé : Konqi est près de deux fois plus rapide pour le rendu CSS, mais en revanche c'est une vraie daube pour le scripting (et je confirme : dès qu'une page contient du bon gros Javascript, comme la barre DLFP sur une dépêche avec plein de commentaires, Konqi s'effondre et me présente l'infâme message « un script sur cette page entraîne le gel de kHTML… »).

          Envoyé depuis mon PDP 11/70

      • [^] # Re: Utilisation de Safari ?

        Posté par (page perso) . Évalué à 1.

        Est-ce que tu as essayé avec Camino ? Il utilise le moteur Gecko, mais que pour les pages web, pas pour construire l'interface. Et il me semble qu'il est plus rapide que FF/Moz. C'est vrai que sous MacOS X, FF et Moz sont des vrais escargots... C'est là : http://www.caminobrowser.org/(...)
        • [^] # Re: Utilisation de Safari ?

          Posté par (page perso) . Évalué à 3.

          > Il utilise le moteur Gecko, mais que pour les pages web, pas pour construire l'interface.

          Hélas, à ma connaissance Gecko insiste pour utiliser son jeu de widgets multi-plateformes, indépendamment de l'utilisation de XUL pour l'interface ou non. Du coup, si la page Web a le moindre élément de formulaire, son interface rompt complètement avec l'environnement graphique local. Un exemple parmi d'autres à [http://galeon.sourceforge.net/graphics/shots/fonts.png(...)] (note la gueule des contrôles en haut de la page).

          Envoyé depuis mon PDP 11/70

          • [^] # Re: Utilisation de Safari ?

            Posté par (page perso) . Évalué à 5.

            Ca, ce n'est qu'un probleme mineur, on peut se debrouiller pour faire ressembler suffisamment ces elements aux elements natifs.

            Le probleme, c'est surtout que gecko fait le choix de laisser les elements de formulaires etre stylés via CSS completement, chose impossible a faire avec les widgets natifs, qui ne permettent pas suffisamment de liberté niveau stylage.

            Safari fait le pari opposé, et ne laisse que peu de possibilités de stylage, justement pour etre cohérent avec l'environnement.

            En bref, on a 2 écoles différentes...
    • [^] # Re: Utilisation de Safari ?

      Posté par . Évalué à 6.

      Le gros intérêt de Safari sur FireFox c'est son intégration dans Mac OS X.

      Un exemple : Mac OS X propose dans ses réglages réseaux de paramétrer le proxy à employer et Safari utilise le dit réglage ensuite. Donc lorsqu'on déplace son portable d'un lieu à un autre il suffit de changer de configuration active pour que Safari sache s'il doit ou pas utiliser un proxy et lequel. A l'inverse avec FireFox après avoir changé de configuration réseau active on doit encore changer le réglage du proxy dans FireFox...

      Autre exemple : la gestion des cookies, Safari les stocke dans un endroit bien défini du système. Si on s'identifie sur un site via un cookie en utilisant Safari, toute application Cocoa désirant faire un accès au site en question va être automatiquement identifiée également.

      ----
      Sinon je ne pense pas que KDE ait intérêt à abandonner khtml, en revanche GNUstep aurait sans doute plus l'utilité d'utiliser WebCore.
  • # Webcore/gtk

    Posté par (page perso) . Évalué à 9.

    Tiens en faisant une recherche gogol sur KHTML, je tombe là-dessus :
    http://gnomedesktop.org/node/2014?PHPSESSID=af47f5f584ce24abb62cf9f(...)
    Les gars de Nokia (!) ont porté relativement récemment (fin octobre 2004) le moteur webcore de Apple pour gtk.
    Euh tiens, dans la page des liens du site, il y a d'autres projets qui basé sur webcore/gtk : atlantis et même un hack pour faire marcher galeon avec webcore... Étonnant non ?

    * gtk-webcore : http://gtk-webcore.sourceforge.net(...)
    * atlantis : http://www.akcaagac.com/index_atlantis.html(...)
    * hack galeon : http://sourceforge.net/mailarchive/forum.php?thread_id=5818624&(...)
    • [^] # Re: Webcore/gtk

      Posté par (page perso) . Évalué à 1.

      Etonnant?
      Plus ou moins
      Plus quand on voit ce que donne gnome "vs" kde
      Moins en sachant que sous unix tout est modulaire (enfin tout les modules font une chose et le font bien)mais aussi d'avoir le choix
      donc ici on a le choix du module
      Enfin en tout cas c'est une bonne initiative :)
      (Bon par contre à packager avec des vrais descs c'est amusant)
  • # michel

    Posté par . Évalué à 10.

    ptain, y a un ramassis de bêtises dans la news et parmi les commentaires

    -------

    cela fait depuis le début qu'apple a maintenu sa propre branche de khtml nommée Webcore

    c'est logique, parce qu'apple a viré toute reference à QT ou autre pour seulement Quartz, et toutes les technologies propres à osx

    bien des fonctions graphiques utilisées dans le rendu de Webcore sont écrites dans d'autres part d'osx

    elles existent pas sous linux, en tout cas pas dans kde

    il ne suffit pas d'adapter le code de webcore pour faire identique dans konqueror. il s'agit parfois de réécrire des choses équivalents à Quartz, à quicktime etc

    Safari est pas simplement "webcore + une interface toute conne".
    si safari est meilleur que Firefox c'est dans l'intégration avec le reste de l'os et cela va très loin

    l'exemple des "cookies" donnée plus haut est incomplet

    Safari (et toute application native à osx) utilise le trousseau de clé intégré à osx pour stocker les identifications et mot de passe . bilan -> quand vous avez demandé à safari de mémoriser vos mots de passe d'un site web , toute vos applications internet peuvent utiliser ces informations pour aller lire le site.
    c'est très pratique, c'est l'une des multiples intégrations entre applications natives d'osx. il y a des centaines d'exemples similaires (les services, le inputmanager, le dictionnaire, etc )

    firefox comme par hasard ne profite d'AUCUNE de ces technologies. Ni même le correcteur orthographique intégré, ni rien.
    Safari est meilleur que firefox pour l'ensemble du confort qu'il hérite naturellement par l'usage de Cocoa.

    -------

    Apple a jamais développé d'équivalent de direct 3d ou Opengl. apple a utilisé opengl depuis que ca leur était utile et c'est devenu totalement dépendant d'opengl dès osx 10.0
    (os x 10.0 ne faisait pas du "extrem quartz" mais c'était le standard utilisé pour faire des jeux en 3D sur mac, pas de direct3D ou autre )

    il y a quicktime3D qui a rien à voir avec le fait de faire des polygones et des vertex-bidule sur carte nvidia ou ati. apple a pas cherché à faire sans opengl , à la Microsoft.

    ----------

    apple étant une société (américaine de sucroit) elle est forcément maléfique comme microsoft et vient de l'enfer
    mais que cela soit avec GCC ou KHTML ils ont simplement respecté la licence gpl
    et on permis à des morceaux entier du systeme d'être accessible au passionné et aux développeur

    qu'est ce que je m'en fiche si Webcore est devenu indépendant de KHTML ! ca reste quand même une très bonne lib qui est LGPL

    cela a permis à des développeurs comme de Omnigroup de modifier webcore, de l'adapter à leur usage pour faire un logiciel qui va plus loin encore que ce qui fut prévu pour Safari
    si webcore n'était pas un logiciel libre (genre moteur html de ie) ,ce qu'à fait omnigroup aurait été impossible.

    il faut bien réaliser que apple a forké des projets pour non seulement les adapter le plus possible à un système qui n'est PAS linux ET à des technologies qui leur sont propres
    faire un arbre commun revient à intégrer 2 branches totalement incompatible de toute façon.

    redhat ou novell ou suse n'ont pas du tout les même considérations que Apple
    Apple est dans une situation similaire à Sun si on veut.

    ---------------

    apple fait exactement ce que demande la licence.
    si vous aviez imaginé des "devoirs" fantaisistes du genre "faut documenter, faut écrire un bo changelog, faut boire du thé avec les autres développeurs" ben figurez vous que Stallman a pas du tout voulu obliger cela en écrivant cette licence.

    -----

    et dans le genre Apple est un Gros méchant de l'enfer. je rappelle que l'entreprise a plusieurs fois changé la licence du noyau d'osx pour satisfaire la FSF. rien n'obligeait Apple à faire cela à part pour se donner une bonne image. cela me va très bien.

    -------------

    une bonne fois pour toute WEBCORE n'est PAS khtml avec des correctifs pour faire "plus compatible"
    c'est KHTML qui fut Adapté, nettoyé et totalement réorganisé pour avoir un moteur html qui utilise TOUTES les technologies NATIVES (et pas disponible pour autre chose) d'OS X

    il était naturel que très vite, les modifs d'apple soient totalement impossibles à remettre dans le khtml sans un travail délirant. (l'exemple bien expliqué des css-shadow est un appel au sous système graphique d'osx qui fait _tout le job_ . y a rien d'équivalent dans KDE (non et même pas Cairo ou Pango ) .


    bref ,FIN de polémique. y a que des attitudes naturelles la. et maintenant des gens de kde essaient de calmer la machine médiatique et la masse des forum qui sont partis dans le pure délire à la X-files.
    • [^] # Re: michel

      Posté par (page perso) . Évalué à 2.

      Safari est pas simplement "webcore + une interface toute conne".
      si safari est meilleur que Firefox c'est dans l'intégration avec le reste de l'os et cela va très loin

      l'exemple des "cookies" donnée plus haut est incomplet

      Safari (et toute application native à osx) utilise le trousseau de clé intégré à osx pour stocker les identifications et mot de passe . bilan -> quand vous avez demandé à safari de mémoriser vos mots de passe d'un site web , toute vos applications internet peuvent utiliser ces informations pour aller lire le site.
      c'est très pratique, c'est l'une des multiples intégrations entre applications natives d'osx. il y a des centaines d'exemples similaires (les services, le inputmanager, le dictionnaire, etc )

      firefox comme par hasard ne profite d'AUCUNE de ces technologies. Ni même le correcteur orthographique intégré, ni rien.
      Safari est meilleur que firefox pour l'ensemble du confort qu'il hérite naturellement par l'usage de Cocoa.


      tout a fait d'accord mais j'ai un petit commentaire
      Ce que tu raconte ca ressemble très fortement à konqueror sur KDE :p
      Donc en suivant ton raisonement konqueror est mieux que firefox
      Oui bon c'est vrai donc c'est un bon syllogisme vrai :)

      qu'est ce que je m'en fiche si Webcore est devenu indépendant de KHTML ! ca reste quand même une très bonne lib qui est LGPL
      indépendant.....
      C'est quand même un fork
      Ils ne sont plus compatible en grande partie mais y a quand meme certaines (petites?) parties qu'on peut échanger

      et dans le genre Apple est un Gros méchant de l'enfer. je rappelle que l'entreprise a plusieurs fois changé la licence du noyau d'osx pour satisfaire la FSF. rien n'obligeait Apple à faire cela à part pour se donner une bonne image. cela me va très bien.
      toutafait


      bref ,FIN de polémique. y a que des attitudes naturelles la. et maintenant des gens de kde essaient de calmer la machine médiatique et la masse des forum qui sont partis dans le pure délire à la X-files.
      He je tiens à mes trolls!
      • [^] # Re: michel

        Posté par . Évalué à 2.

        Ouaip, genre kdewallet...
    • [^] # Re: michel

      Posté par (page perso) . Évalué à 1.

      tout ca c'est très, très bien mais Webcore utiloise toujours les css avec khtml-* il me semble ...
      et ca, c'est très très mal ...

      Par contre, je suis actuellement en recherche de navigateur web mieux intégré au système, moins lent et avec quelques fonctionnalités en plus (correcteur ortho sur konqueror ?) ...
      Cepandant, konqueror ne me convient pas car on ne peux pas le personnaliser facilement (sans personnaliser en même temps le gestionnaire de fichiers) ...

      Existe-t-il un navigateur utilisant webcore ou khtml qui ne soit pas konqueror mais propose tout de même psa mal de fonctionnalités ?

      -----

      Sinon, j'espère que cela mènera a un rapprochement de webcore et khtml, ce serait bien pour le respect des standards et pour tout le monde ...
      peut être pouraient-ils travailler ensemble ... Apple faisant des patchs rapides pour les choses urgentes et KHTML travaillant en parallèle a coté avec l'aide d'Apple...
      • [^] # Re: michel

        Posté par . Évalué à 4.

        Est ce que Configuration > Configurer les profils d'affichage pourrait t'aider ? Après tu peux charger les différents profils avec des options de la ligne de commande.
    • [^] # Re: michel

      Posté par . Évalué à 5.

      >Apple a jamais développé d'équivalent de direct 3d ou Opengl.

      Si : QuickDraw 3D. Il existait meme des cartes d'accélerations dédiées.

      Il existed'ailleurs un projet qui implémente QuickDraw 3D au dessus d'OpenGL :

      http://www.quesa.org/
  • # Santa Barbara

    Posté par . Évalué à 5.

    http://www.zdnet.com.au/news/software/0,2000061733,39191656,00.htm(...)

    Le Lead Dev de FireFox s'en rentre dans la danse, il désapprouve le comportement de l'équipe de KDE.
    Il annonce en substance que WebCore est largement supérieur a KDE, et que Apple avait tous a fait le droit de faire le minimum. Que les développeurs de KDE devrait être moins exigent, corriger plus de bugs plus vite et sortir leurs produits dans les temps.

    A quand le prochain épisode ? Manque plus que Opera et IE.
    • [^] # Re: Santa Barbara

      Posté par (page perso) . Évalué à 0.

      Le Lead Dev de FireFox s'en rentre dans la danse, il désapprouve le comportement de l'équipe de KDE.
      Ouuuueeeeeeeeeeecccccccchhhhhhhhhhhhh

      Il annonce en substance que WebCore est largement supérieur a KDE, et que Apple avait tous a fait le droit de faire le minimum.
      s/kde/khtml/

      A quand le prochain épisode ? Manque plus que Opera et IE.
      Et links?
      et dillo?
      (pourquoi penser au proprio des le début?)
      • [^] # Re: Santa Barbara

        Posté par . Évalué à 3.

        Links a son microcosme, avec Lynx, Elinks etc etc etc ... On ne compte plus les forks dans le domaine des naviguateurs textes.

        Dillo, il est reservé pour le troll sur GTK2 vs Qt vs un bibliothéque quelqu'on que.

        Il restait plus que du proprio.
    • [^] # Re: Santa Barbara

      Posté par (page perso) . Évalué à 10.

      Je reprends ce que j'ai dit sur la mailing-list "pompeur" :

      Il est bien sympa Ben en critiquant l'équipe de KDE, en disant que Safari est
      largement meilleur que Konqueror et en disant que Apple a respecté la licence
      donc qu'ils n'ont rien à dire.

      Si j'ai bien suivi les dernières nouvelles, la Fondation Mozilla a posé des
      restrictions sur l'utilisation des mots Firefox et Mozilla. Or Apple utilise
      toujours "khtml" pour son fork de KHTML ce qui a entraîné et entraîne
      toujours des problèmes.

      Premièrement, quand Apple a annoncé sa sortie de Safari en disant qu'il était
      basé sur KHTML il n'a pas suffisament précisé qu'il avait fait un fork de
      KHTML. Donc beaucoup de développeurs et de site-webs on considéré que tester
      un site sur Safari suffisait et que ça roulerait pour Konqueror. Des sites
      qui avaient fait des comparatifs des propriétés reconnues par les différents
      navigateurs ont complétement fait disparaitre toute allusion à Konqueror en
      précisant de se référer à Safari. Bref Konqueror n'existait pas beaucoup mais
      la pub d'Apple pour son "Safari basé sur KHTML" a tué toutes références à
      Konqueror. Même Tristan ne le cite jamais sur son Standblog :)

      Ca a aussi entrainé de nombreux mécontentements d'utilisateurs ou
      développeurs-webs venu raler auprès de l'équipe KDE (via mail, bugzilla,...)
      pour dire "Ca marche avec Safari, qu'est ce que vous foutez ? Alos vous
      appliquer le patch quand ?". Ils pensent que Apple fournit des patchs à
      l'équipe KDE ce qui n'est pas le cas. A chaque version de Safari tout le
      source est mis à disposition. Les développeurs KDE doivent se taper le source
      pour voir ce qu'il y a de nouveaux. Et quand ils y arrivent ils tombent sur
      de l'Objective C, l'utilisation de couches native de Mac OS X.,.... ce qui
      est normal mais ça n'aide pas l'application des patchs que les utilisateurs
      attendent en ralant.

      Apple a accès au modification du code de KHTML et aux mailing-list de KDE.
      L'équipe de KDE a accès à des tarballs dès qu'une version de Safari est
      disponible.
      L'équipe KDE a le droits aux gens qui ralent parce qu'ils veulent la même
      chose que Safari.
      Apple n'a aucune plainte d'utilisateurs leur demandant d'implémenter les
      choses que Konqueror a mais pas Safari (il y en a peu mais il y en a).
      Bref la coopération ne va que dans un sens.

      Qui plus est, Webcore s'identifie comme KHTML et les propriétés CSS
      spécifiques à Webcore commencent par -khtml-... ce qui fout la grouille.
      Apple aurait dû forker intégralement en utilisant -webcore-...  

      Et je rajoute suite à "Que les développeurs de KDE devrait être moins exigent, corriger plus de bugs plus vite et sortir leurs produits dans les temps" :
      L'équipe qui travaille sur KHTML travaille aussi sur les librairies KDE et sur Koffice. Contrairement à l'équipe Mozilla ou Safari, ils ne développent pas uniquement pour le navigateur et son en effectif beaucoup plus réduit. Et malgré ça Konqueror avance à grand pas. Ils ont déjà intégré les modifs pour passer une partie du test Acid2 ; Konqui 3.4 supporte la propriété text-shadow et les compteurs CSS ; il supporte aussi le SVG animé. Et pour tout ça Mozilla ne le fait pas encore.

      Ben n'a pas totalement tord mais je le trouve insultant vis à vis de l'équipe KDE.

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

  • # Petit résume en 18 points

    Posté par (page perso) . Évalué à 9.

    Petit résumé posté chez un developpeur kde:
    http://www.kdedevelopers.org/node/view/1049(...)

    Ca a le mérite de clarifier un peu le bordel ambiant, et peut etre d'eviter que tout le monde se tape dessus sans comprendre...
  • # apple à la traine

    Posté par . Évalué à 3.

    J'utilise konqueror lorsque je suis sur KDE
    J'utilise firefox sinon (avec wmaker par ex. si je ne veux pas charger mon système)
    Sur mon ibook j'utilise Safari qui est plus réactif que Firefox ou Camino (latence pour changer d'onglet par ex.)

    Je pense que les dev. d'Apple ont fait du bon boulot avec Safari, seulement apparemment c'était surtout un coup marketing leur "collaboration avec l'open source". On le voit avec leur support des applications x11 qui traîne la patte, le support des systèmes de fichiers linux complètement inexistant (ext3, reiserfs) il parait même que le module libre (ext2fsx) pour monter des partitions ext3 sous osx ne fonctionne plus avec le dernier mac os x Tiger (apple doit ne rien en avoir à faire que des utilisateurs mac aient un double boot).

    C'est dommage car gnu / linux j'y crois, apple j'y crois aussi, je pense qu'en collaborant dans les 2 sens il y avait moyen de faire de superbes choses. L'évolution de mac os x faisant suite à NEXTstep s'est très bien faite, en gardant vraiment la philosophie de next. Mais avec les ipoderies qui montent à la tête d'apple, je crois qu'ils perdent un peu de la philosophie next, et que cela entrave un peu leur collaboration avec le libre.

    Comme a dit justement qqu'un, il faut laisser le temps à Apple de peut-être s'y faire, on verra ce que cela donnera dans le futur.
    Je n'utilise pas bpc KDE, mais j'espère que ce projet avec khtml continuera loin, c'est bien d'avoir une alternative à gecko !

    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # Et finalement...

    Posté par (page perso) . Évalué à 1.

    ... finalement on apprend que les patchs fournis par Apple on bien aidé...

    http://www.kdedevelopers.org/node/view/1129(...)

    ... "Konqueror now passes Acid2"

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.