Journal WebKit pour Windows : sortie de Swift alpha !

Posté par  .
Étiquettes : aucune
0
7
août
2006
WekKit est le fork fait par Apple du moteur de rendu KHTML utilisé par Konqueror. Le projet GetWebKit a sorti récemment son navigateur (swift) qui en est issu : http://www.getwebkit.org/
Le projet en est à une version alpha et de nombreux bugs subsistent. Je vous ai fait une petite capture d'écran : http://lezardbreton.free.fr/swift/swift1.jpg (démarrage par défaut).
Les champs de mot de passe ne passent pas encore : http://lezardbreton.free.fr/swift/swift2.jpg

Ca fait donc un autre moteur de rendu mature pour Windows ! Je ne vois pas de détails sur la licence utilisée par contre. Bientôt des spreadswift.org ?

Je rappelle du côté de KDE, le projet Unity a pour but de rapprocher le code de webkit et de KHTML (voir http://dot.kde.org/1152645965/ ).

  • # Mature ou alpha ?

    Posté par  . Évalué à 3.

    faudrait savoir :)

  • # Et encore un...

    Posté par  . Évalué à -5.

    Pourquoi tout le monde aime réinventé la roue ???

    • [^] # Re: Et encore un...

      Posté par  . Évalué à 10.

      C'est vrai ça, on a déjà Internet Explorer sous Windows ...

      • [^] # Re: Et encore un...

        Posté par  . Évalué à 3.

        il y a firefox, opera... qui sont multiplateformes, contrairement à celui-là. Tant qu'à faire, un autre navigateur basé sur khtml / webkit gagnerait plus à être multiplateforme, enfin, ils sont bien libres de développer pour ce qu'ils veulent n'est-ce pas... (et moi de rester sous konqueror... et de penser que les projets "open source" uniquement sur une plateforme complètement fermée ne servent rien à rien). Mais un navigateur léger (encore plus que konqueror, qui nécessite des dépendances) sous linux ne serait pas un mal.

        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

        • [^] # Re: Et encore un...

          Posté par  . Évalué à 3.

          Personnellement, je pense que faire la même interface pour tous les OS est une erreur de conception. Une interface qui s'intègre à Windows n'est pas la même qu'une interface pour KDE. L'exemple parfait est Firefox, avec son interface d'ouverture des exécutables qui oblige à passer par /usr/bin. Bon, ça, c'est la théorie. Comme vous pouvez voir sur les screenshots, l'interface de Swift n'est pas vraiment windosienne. Je suis persuadé que konqueror sous Windows ne sera pas une réussite d'intégration, au moins au début.
          Enfin bon, plus il y a de monde sous KHTML, meilleur c'est !

          • [^] # Re: Et encore un...

            Posté par  . Évalué à 4.

            avec son interface d'ouverture des exécutables qui oblige à passer par /usr/bin


            oui, j'ai trouvé plutôt cela mal vu, et c'est également ce qui m'a poussé à passer sous konqueror, même si j'utilise encore firefox, galeon etc.

            Sous macosx il y a Camino qui reprend le moteur gecko, est proche de firefox, mais est plus adapté au système.

            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

          • [^] # Re: Et encore un...

            Posté par  (site web personnel) . Évalué à 5.

            Ton exemple sur firefox est mal choisi: c'est un bug. Enfin, c'est surtout que personne n'a fait de patch pour https://bugzilla.mozilla.org/show_bug.cgi?id=346870 (c'est surement un dupe, mais bon peu importe la)

            Firefox implemente deja une interface "gnomifiée" sous linux, avec d'ailleurs des changements qui font grincer ceux qui passent de windows a linux.

            Sinon, pour swift, faut laisser un peu le temps aussi. Peut etre qu'il yaura des améliorations coté interface. Peut etre que quelqu'un fera un navigateur un peu plus intégré a windows avec. Enfin, ce qui est important c'est surtout d'avoir WebKit sous windows, ca ne peut que faire du bien a une lib d'etre portée et utilisée :-)

            • [^] # Re: Et encore un...

              Posté par  . Évalué à 1.

              Cette interface me fait aussi "grincer des dents", moi qui vient de... linux. Même avec le C-L puis taper le nom direct de l'exécutable, je comprends pas pourquoi il *faut* qu'il aille me montrer le fichier dont j'ai tapé le nom, avec tout ce que ça implique de temps de lecture (à mon avis il se contente pas d'un simple readdir).

        • [^] # Re: Et encore un...

          Posté par  . Évalué à 10.

          Je me souviens d'un développeur de LL qui disait qu'un des intérêts de porter des logiciels n'était pas forcément de pouvoir l'utiliser sur de nouvelles plateformes, mais que c'"tait un bon moyen de:
          - pointer les erreurs de conception
          - montrer des erreurs de programmation qui sont passées à cause d'un comprtement "magique" de la plateforme originale
          - que généralement, un code portable est signe de qualité, même si les ports ne sont presque pas utlisés

          >Mais un navigateur léger sous linux ne serait pas un mal.
          WebKit existant sous OSX, probablement Linux et maintenant Windows, on peut se dire que la couche de compatibilité est "au point" et plutôt réutilisable (encore un avantage du port Windows). Par exemple, avec un toolkit "léger" genre FLTK ou Fox (ou en utilisant aalib/libcaca ;)). Un volontaire ? :)

          • [^] # Re: Et encore un...

            Posté par  . Évalué à 3.

            Et pourquoi pas tout simplement GNUstep pour réutiliser le code Objective-C ?

            BeOS le faisait il y a 20 ans !

    • [^] # Re: Et encore un...

      Posté par  . Évalué à 6.

      En quoi réinventent-ils la roue ? Au contraire, ils reprennent un moteur de rendu déja existant.

    • [^] # Re: Et encore un...

      Posté par  . Évalué à 1.

      Gné ? Je coris que t'as pas tout suivi là :)
      Au contraire, le but est de réutiliser le code de KHTML...

  • # Performance et qualité du code ?

    Posté par  . Évalué à 6.

    Deux questions, une sur la performance, une sur l'architecture du code :

    - Combien de temps pour afficher about:blank depuis le démarrage sur un laptop moyen ?

    - Combien de mois de refactoring pour diminuer le temps d'affichage de about:blank de 10 millisecondes ?

    • [^] # Re: Performance et qualité du code ?

      Posté par  . Évalué à 5.

      Eh bien, tu seras surpris du résultat ! Sur ma machine du boulot (windows 2000), tout ça prends très exactement 0 (zéro) ms. En fait, juste après avoir double-cliqué dessus, c'est le temps qu'il lui faut pour crasher ... vraiment super rapide :-)

      Pouf, je suis plus là !

    • [^] # Re: Performance et qualité du code ?

      Posté par  . Évalué à 3.

      Sur le temps d'affichage, c'est très rapide. C'est presque comparable à Opera. Mais c'est vrai que ça crashe pas mal, un peu normal pour une alpha en même temps.

    • [^] # Re: Performance et qualité du code ?

      Posté par  (site web personnel) . Évalué à 5.

      Et aussi:

      - Combien de millions de fois le code du Style Engine (ou équivalant) est appelé pour afficher le about:blank



      Référence: https://linuxfr.org/comments/740917.html#740917

      • [^] # Re: Performance et qualité du code ?

        Posté par  (site web personnel, Mastodon) . Évalué à 1.

        tu as mal lu :

        C'est combien de fois est appelé le code du style engine, à partir du moment où tu lance firefox jusqu'à la fin de l'affichage de la page d'accueil abou:blank.

        Ce qui n'est pas pareil, puisque gecko sert à afficher non seulement les pages web, mais aussi l'interface (qui est en XUL, donc du XML +CSS).

        Avec plus de 2500 DOMElement pour la page XUL de Firefox (ça veut pas dire qu'il y a 2500 balises XUL dans la page XUL, car cela compte en fait le code des XBL mis en oeuvre) et 250 regles CSS pour le XUL (sans compter les rêgles CSS du theme)...

    • [^] # Re: Performance et qualité du code ?

      Posté par  . Évalué à 3.

      J'ai testé il y a quelques mois le projet gtk-webcore. C'est un peu vieux, Webkit a surement évolué depuis mais la base reste la même.

      Le chargement etait très rapide, rien à voir avec un navigateur basé sur Gecko. Je dirais que pour un premier lancement, cela tourne autour de 1 à 2 seconde pour que l'application soit utilisable. Sur cette même machine (P4 HT 3Ghz), charger Firefox prend dans les 7 à 8 secondes.

      Donc vivement qu'un portage GTK soit fait pour que je puisse enfin abandonner l'ogre (en temps processeur et en RAM) qu'est Gecko.

  • # K-Meleon

    Posté par  (site web personnel) . Évalué à 1.

    ...et sinon, K-Meleon 1.0 est sorti : il est stable et mature... http://kmeleon.sourceforge.net/

Suivre le flux des commentaires

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