Journal Konqueror un peu plus rapide

Posté par  (site web personnel) .
Étiquettes :
22
27
fév.
2010
Bonjour,

Dans ce contexte de «guerre de la rapidité» entre navigateurs, et surtout entre FireFox et Chrome, personne ne s'est trop intéressé à Konqueror, le navigateur web de KDE.

En effet, Konqueror utilise KHTML et KJS, qu'il est à peu près le seul à utiliser, donc ça intéresse moins de monde. De plus, KJS est très lent, ce qui fait que les chiffres de benchmarks Javascript sont moins beau que pour FireFox ou Chrome (à vue de nez et si mes souvenirs sont bons, Konqueror est à peine plus rapide qu'IE 8).

Néanmoins, une "petite" optimisation a été apportée hier dans la version SVN de KHTML, n'accélérant en rien le Javascript, mais plutôt le rendu HTML.

Voici les deux commits apportant cette modification :


r1096620 | ggarand | 2010-02-27 04:31:52 +0100 (sam 27 fév 2010) | 8 lignes
Chemins modifiés :
M /trunk/KDE/kdelibs/khtml/misc/loader.cpp
M /trunk/KDE/kdelibs/khtml/misc/loader.h

port KHTML to Andrea's excellent scheduler.

This, together with the next patch, greatly improves Konqueror's
objective speed (Page Loading Time) as well as the subjective speed
(Time To First Paint).
Our PLT was already very nice, but this just blows things off.
Will have to explain that in greater details, because it's just
beautiful :-)
------------------------------------------------------------------------
r1096621 | ggarand | 2010-02-27 04:32:03 +0100 (sam 27 fév 2010) | 5 lignes
Chemins modifiés :
M /trunk/KDE/kdelibs/khtml/khtml_part.cpp
M /trunk/KDE/kdelibs/khtml/khtmlview.cpp

improvements of resources scheduling and overall speed
progress of KIO over the past year(s) allow to greatly optimize the paint
suppression and initial layout delay algorithm.

TTFP is halved on most pages, without any flashing!


Quand j'ai vu ça, j'ai tout de suite recompilé les kdelibs, puis relancé Konqueror.

Tout est assez subjectif, mais la rapidité est bien là. Konqueror a toujours été assez lent, en affichant désespérément une page blanche avant que tout ne soit chargé, puis dessinant le tout lentement.

Ces modifications permettent d'une part de détecter plus vite quand une page peut être dessinée et qu'elle ne changera plus après (donc quand on a tout le HTML, le Javascript et la taille des images), pour pouvoir présenter la page plus rapidement à l'utilisateur.

Le résultat est saisissant sur Linuxfr (surtout la page d'accueil, avec les journaux et dépêches apparaissant au compte-goutte) : dès le bouton «Accueil» cliqué, la barre des menus du haut, l'image avec les pingouins, l'astuce et la dépêche mise à l'honneur apparaissent. Ensuite, les contenus arrivent un à un, suivi de près par leur image. Une fois tout chargé correctement, les petits boutons «Fin de surveillance» font leur apparition.

D'autres sites assez lourds et riches en contenu, tel le planet KDE, se chargent beaucoup plus vite et beaucoup mieux.

Cette modification permet donc de tirer parti de la rapidité de KHTML, sans être freiné par les KIO et le téléchargement d'autres machins. Ce n'est pas encore un Javascript rapide, mais ça rend tout de suite Konqueror bien plus utilisable (et petit effet de bord : quand vous démarrez Konqueror et qu'il restaure plein d'onglets, on sent largement le gain de vitesse qui fait qu'on arrive vite aux pages qu'on avait, et pas devant une fenêtre toute blanche).

Voilà. Ce sera disponible dans KDE 4.5.
  • # Performance javascript

    Posté par  . Évalué à 3.

    Sinon dans un autre registre, mozilla se lance finalement dans un compilateur JIT "classique" (comme safari avec nitro et chrome avec v8) en plus de leur JIT "tracing":

    https://wiki.mozilla.org/JaegerMonkey
    http://blog.mozilla.com/dmandelin/2010/02/26/starting-jagerm(...)
    http://www.bailopan.net/blog/?p=683
  • # De toute façon

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

    De toute façon, je pense que KHTML et KJS n'ont pas vraiment d'avenir, et KDE à tout à gagner à passer à (Q)Webkit. Il reste probablement des problèmes d'intégration à résoudre (kwallet/kauth par exemple), mais rien d'insurmontable.
    • [^] # Re: De toute façon

      Posté par  . Évalué à 3.

      L'intégration à kwallet ne devrait pas être trop difficile, étant donné que l'équivalent vient d'être fait chez le concurrent (ajout du support de GNOME Keyring dans WebkitGTK).

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: De toute façon

      Posté par  . Évalué à -1.

      Oui, je ne vois pas pourquoi ils ne font pas ce passage plus rapidement, voir meme en priorite.
      Je comprend qu'ils aient un attachement sentimental a leur moteur de rendu, mais les avantages strategiques d'utiliser Webkit pour le projet KDE sont a mon avis largement non negligeables
      - l'utilisateur sera mieux satisfait puisqu'il pourra utiliser un navigateur web rapide qui passera mieux sur certains sites
      - les developpeurs auront moins de temps a consacrer au developpement et a la maintenance d'un composant qui semble maintenant assez superflu, en exagerant, on pourrait voir ca comme si KDE developpait sa propre libc
      KDE est un environnement qui semble en perte de parts de marche depuis que les distributions ont pousse l'utilisation par defaut de gnome qui est maintenant mieux integre et moins buggue.
      Je pense que ca leur ferait du bien d'arreter de gaspiller des ressources (si les developpeurs KHTML se redirigent sur autre chose apres bien entendu).
      • [^] # Re: De toute façon

        Posté par  . Évalué à 4.

        Oui, je ne vois pas pourquoi ils ne font pas ce passage plus rapidement, voir meme en priorite.

        Et s'ils n'ont pas envie? Il y a déjà des gens qui bossent sur le port de konqueror vers webkit (rekonq) donc les gens peuvent bosser dans le projet qui les intéressent le plus.

        l'utilisateur sera mieux satisfait puisqu'il pourra utiliser un navigateur web rapide qui passera mieux sur certains sites

        l'utilisateur peut déjà utiliser firefox, arora ou chromium s'il n'est pas satisfait de konqueror.

        les developpeurs auront moins de temps a consacrer au developpement et a la maintenance d'un composant qui semble maintenant assez superflu, en exagerant, on pourrait voir ca comme si KDE developpait sa propre libc

        Et s'ils n'ont pas envie de bosser sur d'autres composant?

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: De toute façon

          Posté par  . Évalué à 1.

          Et s'ils n'ont pas envie? Il y a déjà des gens qui bossent sur le port de konqueror vers webkit (rekonq) donc les gens peuvent bosser dans le projet qui les intéressent le plus.

          Ils font ce qu'ils veulent, bien entendu. Mais c'est ici une question de stratégie pour l'environnement entier, qui va au-delà du simple « loisir » de développer. Il ne faut pas que les gens de KDE s'étonnent qu'il soit de moins en moins utilisé, s'ils gaspillent des ressources à travailler sur des projets qu'ils sont seuls à maintenir.

          Après, il faut savoir ce que l'on veut et s'y tenir : par exemple, Fedora se moque d'avoir ou non des utilisateurs. Ce qu'elle veut, ce sont des développeurs. C'est dit clairement, et la stratégie globale suit cet axiome.

          Pour KDE, je n'ai rien vu de tel, mais j'imagine que leur souhait est de le voir utilisé par le plus grand nombre. À eux de travailler sur les modules les plus à mêmes de permettre d'atteindre ce but.

          l'utilisateur sera mieux satisfait puisqu'il pourra utiliser un navigateur web rapide qui passera mieux sur certains sites

          l'utilisateur peut déjà utiliser firefox, arora ou chromium s'il n'est pas satisfait de konqueror.


          Et celui qui n'est pas satisfait de Konqueror, mais qui souhaite un navigateur parfaitement intégré à KDE ? Je n'en connais aucun au niveau de KDE (Kwallet et KAuth comme dit plus haut, mais aussi KGet, Systemconfig, les kparts, etc).

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: De toute façon

            Posté par  . Évalué à 3.

            s'ils gaspillent des ressources à travailler sur des projets qu'ils sont seuls à maintenir.

            Ce n'est pas du gaspillage, les gens font ce qu'ils veulent. Konqueror est actuellement le meilleur navigateur KDE, le choix est vite fait.

            Et celui qui n'est pas satisfait de Konqueror, mais qui souhaite un navigateur parfaitement intégré à KDE ?

            Il y a rekonq

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: De toute façon

              Posté par  . Évalué à 1.

              Ce n'est pas du gaspillage, les gens font ce qu'ils veulent. Konqueror est actuellement le meilleur navigateur KDE, le choix est vite fait.

              Encore une fois, tout dépend de la stratégie de KDE : s'il souhaite être l'environnement de bureau le plus utilisé, c'est du gaspillage : deux moteurs de rendu sont développés en parallèle.
              Par contre, si leur but est juste l'expertise technique, je suis d'accord qu'il n'y a aucun problème, les dév font ce qu'ils veulent.

              Il y a rekonq

              $ apt-cache search rekonq
              W: Impossible de trouver le paquet rekonq
              E: Aucun paquet n'a été trouvé

              Désolé, je ne peux pas l'utiliser et je n'ai pas envie de le compiler moi-même. Et vu qu'il en est à la version 0.3.90, je ne sais pas s'il est prêt à remplacer Konqueror (bien que je sois conscient que la version ne soit pas forcément significative).

              Encore une fois, je considère que c'est du gaspillage. Pendant que certains travaillent à adapter Konqueror à Webkit, d'autres repartent de zéro pour un nouveau navigateur, et d'autres enfin continuent à maintenir un moteur de rendu que seul KDE utilise.

              Je trouve cela dommage car j'ai toujours considéré KDE comme supérieur d'un point de vue technique, grâce notamment aux Kparts et à des choix de conception judicieux qui permettent d'éviter la redondance et le code inutile, et j'ai bien l'impression de voir exactement le contraire ici.

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: De toute façon

                Posté par  . Évalué à 3.

                Encore une fois, tout dépend de la stratégie de KDE : s'il souhaite être l'environnement de bureau le plus utilisé, c'est du gaspillage : deux moteurs de rendu sont développés en parallèle.

                En quoi c'est du gaspillage, si on arrêtait le développement de KHTML, je suis pas sûr que les développeurs migreraient sur webkit. Il n'y a pas de stratégie pour KHTML, c'est juste le meilleur navigateur KDE qui est choisi pour l'instant.

                $ apt-cache search rekonq
                W: Impossible de trouver le paquet rekonq
                E: Aucun paquet n'a été trouvé


                Et si ta distrib ne package pas firefox, tu diras qu'il n'y a aucun navigateur correct qui package Gecko?

                Encore une fois, je considère que c'est du gaspillage. Pendant que certains travaillent à adapter Konqueror à Webkit, d'autres repartent de zéro pour un nouveau navigateur, et d'autres enfin continuent à maintenir un moteur de rendu que seul KDE utilise.

                Je trouve justement ça très bien, ça veut dire qu'on aura le choix du moteur de rendu (et KDE aime bien laisser le choix à l'utilisateur).

                d'éviter la redondance et le code inutile, et j'ai bien l'impression de voir exactement le contraire ici.

                En quoi c'est de la redondance de code inutile? Ça permet justement le laisser le choix. Comme pour le backend Phonon, tu as xine, gstreamer, vlc. Tu trouves aussi que c'est inutile?

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: De toute façon

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

                  Comme pour le backend Phonon, tu as xine, gstreamer, vlc. Tu trouves aussi que c'est inutile?

                  C'est très utile, mais c'est dommage que ça ne marche pas du tout.
                  • [^] # Re: De toute façon

                    Posté par  . Évalué à 1.

                    Oui le probleme de KDE a l'heure actuelle c'est qu'au lieu de se concentrer sur certaines fonctionnalites et de fournir un produit fini, ils partent dans plein de directions et rien ne marche correctement.
                    C'est dommage l'architecture est propre, le code est propre, mais ca l'utilisateur lambda il s'en fout.
                    • [^] # Re: De toute façon

                      Posté par  . Évalué à -2.

                      Deja dans le negatif hebe
                      Si c'est en acceptant la critique que l'on progresse, c'est pas avec la population d'ici que le libre ira de l'avant.
                      • [^] # Re: De toute façon

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

                        Ah bon, comment veux-tu que ta « critique» fasse progresser quoi que ce soit ? Tu n'apporte aucun élément...

                        Ce n'est pas une critique, ce n'est que ton opinion.

                        Chez moi ça marche très bien d'ailleurs.
                        • [^] # Re: De toute façon

                          Posté par  . Évalué à 2.

                          Ce n'est pas une opinion, c'est un fait.
                          Il y a un manque de controle qualité et beaucoup de problèmes gênant pour un utilisateur normal persistent.

                          Ca me semble tellement évident que je n'ai pas pris la peine de donner des exemples, mais en voila quelques uns :
                          https://bugs.kde.org/show_bug.cgi?id=185544
                          https://bugs.kde.org/show_bug.cgi?id=227483
                          https://bugs.kde.org/show_bug.cgi?id=186872
                          https://bugs.kde.org/show_bug.cgi?id=227144
                          https://bugs.kde.org/show_bug.cgi?id=163544

                          En concret ca veut dire quoi ?
                          - Kontact crash a chaque demarrage de session si je ne le ferme pas une premiere fois
                          - Je peut pas utiliser kopete derriere un proxy
                          - Mes plasmoides deviennent parfois bizarres
                          - Pas possible de controler pulse audio, donc impossible de changer le périphérique d'enregistrement par défaut => impossible d'utiliser les micros secondaires integres a une webcam par exemple

                          Tout ca sur une install fraiche.
                          Honnetement, si tu voulais montrer à quelqu'un que linux c'est bien, tu lui installerai un environnement de bureau qui as ces problèmes ?
                          • [^] # Re: De toute façon

                            Posté par  . Évalué à -1.

                            J'installerai pas PulseAudio déjà !
                            • [^] # Re: De toute façon

                              Posté par  . Évalué à 2.

                              Oui, et moi non plus je ne le fait pas.
                              Mais un utilisateur normal (non geek) ne sais même pas ce que c'est, et n'a pas a le savoir.
                  • [^] # Re: De toute façon

                    Posté par  . Évalué à 5.

                    Je n'ai aucun problème avec Phonon. Tu ne serais pas sur Ubuntu par hasard?

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: De toute façon

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

                      Avec quel backend ? Tu utilises Amarok ?
                      • [^] # Re: De toute façon

                        Posté par  . Évalué à 2.

                        j'ai déjà utilisé xine et gstreamer et avec Amarok.

                        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                        • [^] # Re: De toute façon

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

                          Effectivement, il y a deux des backend qui ne sont pas fonctionnels (vlc et mplayer, qui sont dans KDE playground, et non packagés dans Debian), ce qui ne laisse que deux backends, un peu léger pour une couche d'abstraction.

                          Et si en fait tu te penches un peu plus sur la question, tu te rend compte que le backend gstreamer marche assez mal, notamment avec amarok : un certain nombre de fichier ne marchent pas (voir le bug tracker KDE).

                          Et si tu lis un peu les rapports de bug debian, tu trouves « This is a known bug. Please, stay with the xine backend », ce qui ne tend pas à faire croire que ça marche bien.

                          Enfin, jusqu'à il y a peu, le seek avec amarok et le backend xine ne marchait pas bien du tout, et parfois les morceaux commençait après le début, mais je viens de tester et ça marche correctement. Il y a donc un backend qui marche bien, ça valait le coup de faire une couche d'abstraction ;)
                          • [^] # Re: De toute façon

                            Posté par  . Évalué à 2.

                            La couche d'abstraction est aussi là pour permettre une évolution du backend tout en gardant une compatibilité des applis (il me semble que des développeurs s'étaient plaint de ça).

                            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                            • [^] # Re: De toute façon

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

                              À toi et au commentaire plus bas : le commentaire auquel je répondais à l'origine disait : xine, gstreamer, vlc. Je faisais juste remarquer qu'un seul ne marchait en réalité.

                              Après une couche d'abstraction pour un seul backend, bof, autant faire une couche de compat dans le soft original…
                              • [^] # Re: De toute façon

                                Posté par  . Évalué à 2.

                                C'est un peu de la duplication de code inutile. Et puis le but des autres backend, c'est de les faire fonctionner à terme.

                                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                                • [^] # Re: De toute façon

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

                                  Qu'est-ce qui est un peu de la duplication de code inutile ?

                                  Je suis bien d'accord que le but c'est que ça marche, d'où mon commentaire : c'est très utile, mais c'est dommage que ça ne marche que pour un seul backend (pour l'instant).
                                  • [^] # Re: De toute façon

                                    Posté par  . Évalué à 2.

                                    Si toutes les applications qui émettent un son doivent adapté leur code si la lib évolue c'est de la duplication de code pour moi. Et tu n'as pas répondu à propos des backend quicktime et [celuisouswindowsdontjenemesouviensplusdunom].

                                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                                    • [^] # Re: De toute façon

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

                                      Si toutes les applications qui émettent un son doivent adapté leur code si la lib évolue c'est de la duplication de code pour moi.

                                      C'est pour ça que je disais, si le but c'est de faire une couche de compat, autant la faire upstream, ça fait encore moins de duplication de code.

                                      Et tu n'as pas répondu à propos des backend quicktime et [celuisouswindowsdontjenemesouviensplusdunom].

                                      Simplement parce qu'étant Linuxien uniquement, je ne savais même pas que ça existait. Effectivement, si ces deux là marchent bien, alors il faut fortement nuancer mon propos initial (à transformer en : c'est très utile, dommage qu'il n'y ait qu'un seul backend de pleinement fonctionnel sous Linux). Il semble d'ailleurs que ce ne soit pas perdu, puisqu'il y a quelque temps, le backend gstreamer n'était clairement pas supporté par amarok (j'étais resté sur cette situation en postant mon commentaire, mais apparement ça a changé depuis, seul l'equalizer ne supporte que le backend xine).
                          • [^] # Re: De toute façon

                            Posté par  . Évalué à 3.

                            Tu utiliseras pas le backend xine sous Windows, MacOS X ou sur d'autres OS comme Haiku je pense. L'abstraction a toute sa place.
                            De plus, si xine décide de faire un libxine2, cassant toute compatibilité des APIs, ben KDE n'aura pas à réécrire chaque appli.
                      • [^] # Re: De toute façon

                        Posté par  . Évalué à 0.

                        Aucun problème ici avec Amarok et Phonon-xine.
                • [^] # Re: De toute façon

                  Posté par  . Évalué à 0.

                  Tu connais des distribs majeures qui packagent pas firefox ?
                  Ton exemple est vachement tire par les cheveux. Ou alors tu defends l'indefendable ...
                  • [^] # Re: De toute façon

                    Posté par  . Évalué à 2.

                    Je veux dire que c'est pas de la faute de KDE si tout les logiciels que tu veux ne sont pas sur ta distrib.

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: De toute façon

                      Posté par  . Évalué à -2.

                      Si un logiciel n'est pas dans une distrib majeure, c'est peut etre parce qu'il n'est pas assez mur ?
                      Le meilleur moyen de faire fuir un utilisateur, c'est de lui balancer des softs qui marchent mal.
                      • [^] # Re: De toute façon

                        Posté par  . Évalué à 4.

                        Donc tu veux que le moteur de rendu change du jour au lendemain et qu'en plus, il soit stable dès qu'il a changé et 100 balles et un mars tant qu'on y est.

                        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                        • [^] # Re: De toute façon

                          Posté par  . Évalué à 1.

                          C'est-à-dire que KDE4 a mis tant de temps à être utilisable qu'ils auraient pu commencer cette migration dès le début, au lieu d'attendre la 4.4, pour un travail qui risque finalement d'être inévitable.

                          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                          • [^] # Re: De toute façon

                            Posté par  . Évalué à 5.

                            Sachant qu'il n'est dans Qt que depuis la 4.4, et que c'est seulement à partir de ce moment là que les travaux ont commencé, je vois mal comment c'était inévitable depuis KDE 4.0.

                            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                            • [^] # Re: De toute façon

                              Posté par  . Évalué à 1.

                              Webkit a commence a etre utilise par d'autres bien avant Qt 4.4, ils ont fait comment ?
                              Le probleme n'est pas que technique.
                              • [^] # Re: De toute façon

                                Posté par  . Évalué à 4.

                                Webkit a commence a etre utilise par d'autres bien avant Qt 4.4, ils ont fait comment ?

                                Sauf que ce n'était pas des applis Qt et encore moins KDE. S'il faut se taper l'intégration Qt et puis l'intégration KDE alors qu'il y avait juste assez de gens pour porter KHTML, c'est pas vraiment possible, la main d'oeuvre ne se créée pas toute seule.

                                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                                • [^] # Re: De toute façon

                                  Posté par  . Évalué à -3.

                                  la main d'oeuvre ne se créée pas toute seule

                                  Tout à fait. Par conséquent, il faut définir des priorités et y allouer des développeurs, plutôt que de partir dans tous les sens.

                                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                                  • [^] # Re: De toute façon

                                    Posté par  . Évalué à 4.

                                    Les développeurs sont bénévoles, ils font ce qu'ils veulent et ils doivent maintenir KHTML tout au long de la branche 4 et ne sont déjà pas nombreux, ça risque d'être difficile. Et tu veux les retirer d'où les développeurs ? (il faut qu'ils maitrisent le domaine quand même.)

                                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                                    • [^] # Re: De toute façon

                                      Posté par  . Évalué à 6.

                                      De tout de maniere les developpeurs de khtml ne veulent absolument pas bosser sur webkit pour la simple raison qu'ils ont toujours en travers de la gorge la facon de faire de Apple et le fork realise. Sans compter la bataille pour faire respecter la licence.
                              • [^] # Re: De toute façon

                                Posté par  . Évalué à 7.

                                Le probleme n'est pas que technique.

                                En effet. Les développeurs de KDE ont été aux premières loges pour assister aux débuts chaotiques d'Apple en tant que contributeur à un projet libre et communautaire. Ce qui peut les avoir refroidis.
                        • [^] # Re: De toute façon

                          Posté par  . Évalué à 0.

                          Non, je te rappelles que c'est toi qui as balance un "si t'es pas content, t'as qu'a utiliser le machin en version alpha qui existe sur aucun dépot".
                          Moi je veut juste que konqueror deviennes un navigateur viable "dans un avenir pas trop lointain", et il n'est pas sur la bonne voie hélas.
                          • [^] # Re: De toute façon

                            Posté par  . Évalué à 6.

                            Moi je veut juste que konqueror deviennes un navigateur viable "dans un avenir pas trop lointain", et il n'est pas sur la bonne voie hélas.

                            Si tu le veux, il va falloir mettre la main à la pâte, soit en engageant quelqu'un soit en codant toi-même, parce que c'est pas en discutant avec moi que ça va changer.

                            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                            • [^] # Re: De toute façon

                              Posté par  . Évalué à 0.

                              Non
                              Je ne vois pas pourquoi je coderai alors qu'il y a des alternatives, en plus c'est à eux de se mettre à niveau si ils veulent que leur truc soit plus utilisé, dans l'intérêt du projet.
                              Ca a l'air assez a la mode sur linuxfr de rejeter la faute sur les utilisateurs.
                              • [^] # Re: De toute façon

                                Posté par  . Évalué à 2.

                                S'il y a des alternatives qui te convienne mieux, change et n'exige pas que des bénévoles fassent le boulot à ta place.

                                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                                • [^] # Re: De toute façon

                                  Posté par  . Évalué à 0.

                                  Mais je ne l'utilise pas.

                                  Si le but recherche est de toucher plus de gens et de promouvoir un bureau libre, tu ne penses pas qu'une attitude plus constructive serait tout simplement d'ecouter ce que veulent les utilisateurs et d'aller dans ce sens ?
                                  C'est quelque chose que bizarrement peu de gens qui commentent sur ce site ont l'air de comprendre.
                                  • [^] # Re: De toute façon

                                    Posté par  . Évalué à 3.

                                    Mais de toute façon, c'est pas discutable :
                                    1) ils ne peuvent pas, techniquement, abandonner KHTML (conservation de l'API/ABI pour tout KDE 4, ils vont pas lâcher ça, jamais)
                                    2) l'intégration de webkit à KDE est pas évidente (travail en cours, ça a avancé dans KDE 4.4, pour KDE 4.5 peut être que ça sera fini)
                                    3) les développeurs de Konqueror travaillent sur ce qu'ils veulent, personne ne peut empêcher ça
                                    4) in fine, la décision reviendra aux distributions : installeront-elles le kpart webkit et l'activeront-elles par défaut ? Ben oui, les utilisateurs s'en foutent de l'upstream, ils utilisent une distribution. Je suis sûr qu'un utilisateur pourrait utiliser de manière transparente une Debian GNU/Linux, Debian Hurd ou Debian GNU/kFreeBSD, à partir du moment où les pilotes sont au point...
                                    • [^] # Re: De toute façon

                                      Posté par  . Évalué à 0.

                                      1/ Pas un probleme insurmontable : les deux pourraient cohabiter et khtml serait progressivement de moins en moins utilise jusqu'a devenir "deprecated", on pourrait aussi faire un wrapper KHTMLPart implemente par webkit pour maintenir la compatibilite si ca pose vraiment probleme
                                      2/ Oui, mais ca avance
                                      3/ Oui, mais le projet peut donner une direction a suivre, si c'est dans leur interet (et je pense que ca l'est)
                                      4/ Si le kpart webkit est integre au projet KDE en mainstream et qu'il marche bien, il sera sans doute active par defaut
                                  • [^] # Re: De toute façon

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

                                    Tu t'avances beaucoup sur le but recherché... je participe à un autre projet, assez bouffeur de temps, si je n'y prenais pas un certain plaisir, je laisserai tomber. Quand tu codes, que tu documentes, que tu résouds les bogues et que tu mets à jour le site, sans parler du pire, tu as bien autre chose en tête que de "toucher le plus de gens". Au delà du goût pour a gloriole, ça rapporterait quoi?
                                    D'autre part, pendant longtemps (jusqu'à KDE 3.5) le "plus de gens" était essentiellement constitué de gars n'ayant pas peur de mettre les mains dans le cambouis. Du coup, les problèmes que tu évoques, on s'en foutait un peu. Actuellement, le public change mais ça n'est pas encore reflété dans le mode de développement.

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

                  • [^] # Re: De toute façon

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

                    Tu connais des distribs majeures qui packagent pas firefox ?

                    Debian.
                • [^] # Re: De toute façon

                  Posté par  . Évalué à 1.

                  En quoi c'est du gaspillage, si on arrêtait le développement de KHTML, je suis pas sûr que les développeurs migreraient sur webkit. Il n'y a pas de stratégie pour KHTML, c'est juste le meilleur navigateur KDE qui est choisi pour l'instant.
                  KHTML n'est pas un navigateur, c'est un moteur de rendu.
                  La question a se poser c'est «Y a t-il des raisons techniques valables pour conserver KHTML comme moteur de rendu de KDE ?»
                  Si les developpeurs de KHTML veulent continuer a faire evoluer leur moteur, pourquoi pas, mais pourquoi refourguer a l'utilisateur un moteur de rendu moins bon ?
                  Jusqu'a present j'ai plutot l'impression que les developpeurs de KDE font du sentimentalisme.
                  • [^] # Re: De toute façon

                    Posté par  . Évalué à 2.

                    mais pourquoi refourguer a l'utilisateur un moteur de rendu moins bon ?

                    Parce qu'il n'y a pas de navigateur KDE qui supporte Webkit aussi bien que KHTML?

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: De toute façon

                      Posté par  . Évalué à 2.

                      Ca pourrait changer, du point de vue de l'utilisateur c'est juste dommage que ca stagne.
                      Utilisateur insatisfait >> utilisateur qui se detourne du projet >> projet en perte de vitesse
                      Il ne faut pas se voiler la face, KDE n'est pas a l'heure actuelle sur le chemin de devenir le bureau par defaut de la pluspart des distribs majeures.
                      Dommage.
                      • [^] # Re: De toute façon

                        Posté par  . Évalué à 2.

                        La plupart des distrib majeures utilise Firefox comme navigateur par défaut et ce n'est ni KDE, ni Gnome. Comment ça explique que Gnome est le bureau par défaut de la plupart des distribs majeures?

                        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                        • [^] # Re: De toute façon

                          Posté par  . Évalué à 0.

                          KDE a bien d'autres problemes que le moteur de rendu HTML, il y a pas mal de bugs gênant, il suffit de se rendre sur bugs.kde.org pour s'en rendre compte.
                          Je l'utilise au quotidien mais je trouve ca dommage, cet environnement a un bon potentiel mais il fait fuir les utilisateurs parce qu'il n'est pas "fini".
                      • [^] # Re: De toute façon

                        Posté par  . Évalué à 2.

                        KDE est bureau par défaut chez Mandriva et openSUSE.
                        Debian/Fedora et leurs dérivées pour Gnome.
                        • [^] # Re: De toute façon

                          Posté par  . Évalué à 1.

                          Je ne peut pas pretendre que ce sont des statistiques exactes, mais :
                          http://www.google.fr/trends?q=ubuntu%2C+fedora%2C+suse%2C+Ma(...)
                          Ubuntu (et donc Gnome) semble largement en tete.
                          Si quelqu'un a d'autres statistiques recentes sur la popularite des distribs ca m'intérresse.
                          • [^] # Re: De toute façon

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

                            Pour Ubuntu, c'est ridicule.
                            Ubuntu a toujours été livrée avec Gnome.
                            Les premières Kubuntu datent de KDE 3.5.x. Elles étaient l'oeuvre de bénévoles (essentiellement Jonathan Riddell au début).
                            Du coup Ubuntu - version Gnome donc - est toujours mis en avant. Dès lors, rien d'étonnant à ce que le bureau Gnome soit plus utilisé.
                            Et tout ça bien avant la sortie de KDE4.

                            D'ailleurs il en va de même pour Fedora et RedHat.

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

                            • [^] # Re: De toute façon

                              Posté par  . Évalué à 1.

                              Je pense que les gens de chez ubuntu sont assez pragmatique pour ne pas choisir un environnement de bureau par defaut sur un coup de coeur.
                              Je n'aime pas gnome, mais je suis convaincu que si il a ete choisi, c'est en partie parce qu'il y avait moins de travail a faire dessus pour obtenir un environnement de bureau stable.
                              J'utilise KDE depuis les versions 2 et il y a toujours eu des problemes de stabilite, des fonctionnalites qui ne marchent qu'a moitie etc.
                              • [^] # Re: De toute façon

                                Posté par  . Évalué à 2.

                                Je n'aime pas gnome, mais je suis convaincu que si il a ete choisi, c'est en partie parce qu'il y avait moins de travail a faire dessus pour obtenir un environnement de bureau stable.

                                Sachant qu'ils arrivent à y introduire une quantité assez énorme par rapport l'upstream je ne serais pas aussi catégorique.

                                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                            • [^] # Re: De toute façon

                              Posté par  . Évalué à 2.

                              Chez Fedora et Red-Hat (et meme mandriva) c'est pire dans le sens ou tous les outils de configurations sont en GTK.

                              Les seuls distributions que je connaisse qui tente de faire un vrai systeme kde/Qt c'est pardus, opensuse et ubuntu.

                              Malheureusement pour cette derniere tant qu'ils ne respecteront pas la boulot upstream cela sera toujours bancale. Opensuse j'ai tente il y a 1 an mais je n'ai pas accroche, c'est trop facile de peter son systeme avec des depots non restreint a la version que tu utilises. Et donc la derniere, pardus, et a mon avis celle qui a la meilleure integration et qui a le plus de potentiel.
              • [^] # Re: De toute façon

                Posté par  . Évalué à 5.

                deux commentaires pour dire que c'est du gaspillage, je trouve que c'est du gaspillage...
              • [^] # Re: De toute façon

                Posté par  . Évalué à 4.


                $ apt-cache search rekonq
                W: Impossible de trouver le paquet rekonq
                E: Aucun paquet n'a été trouvé


                Ahaha la blague, c'est marrant moi je fait

                $yaourt -Sy rekonq
                Synchronisation des bases de données de paquets.
                ...
                ...
                ...
                Résolution des dépendances...
                Recherche des conflits possibles entre paquets...

                Cibles (1): rekonq-0.3.0-1

                Taille totale des paquets (téléchargement): 0,40 Mo
                Taille totale des paquets (installation): 1,18 Mo

                Procéder à l'installation ? [O/n]

                Mais c'est la faute au projet KDE c'est sûr.
                • [^] # Re: De toute façon

                  Posté par  . Évalué à 3.

                  Je n'ai jamais dit que c'est de la faute de KDE s'il n'est pas packagé. Je dirais plutôt que du fait que ce soit un nouveau projet, il n'est pas encore mûr et donc pas disponible partout.

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: De toute façon

      Posté par  . Évalué à 4.

      Pas avant KDE 5 : KDE maintient la stabilité de son ABI et de son API. Tout au plus KHTML pourrait être déprécié, mais pas supprimé.
  • # Ha bon?

    Posté par  . Évalué à 2.

    Konqueror est à peine plus rapide qu'IE 8

    Tu utilises Konqueror sous Windows? Parce que sur ma Mandriva Cooker, je n'ai pas de problème de lenteur avec Konqueror.
    Bon, il arrive que ça devienne très lent mais c'est lorsque j'ai plus d'une douzaine d'onglets ouverts surchargés en javascript.
    La première chose que j'ouvre habituellement après avoir démarré, c'est DLFP avec Konqueror: temps de chargement < 0,5s. La seule modif que j'ai faite par rapport à la config de base, c'est la désactivation des modules externes (flash,etc).
    • [^] # Re: Ha bon?

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

      Dans le journal « Performances comparées de Javascript sous divers environnements», il y avait le score d'un benchmark Javascript avec IE 8 dedans. Il a eu 6000 au minimum.

      Dans ce benchmark, FireFox avait 1403. Mon FireFox, à ce test, a eu 1600, donc un peu plus. Mon Konqueror a eu 4500-5000, je ne sais plus, c'est à dire à peine plus lent qu'IE8 comparé au reste (donc largement plus lent que Chrome ou FireFox).

      KJS est donc bien le moteur Javascript libre le plus lent, si j'en crois ces tests. Heureusement que le moteur HTML est lui relativement rapide.

      Et puisqu'on parle de KHTML, je trouve dégoûtant ce qu'à fait Apple en le forkant si brutalement, en larguant KHTML. Car on peut dire ce qu'on veut, je troue KHTML bien meilleur (meilleur respect des standards, meilleure intégration à KDE, bien plus prévisible dans tout ce qui est sélections, dessins plus jolis (arrondis des cadres, intégration des KParts pour afficher les contenus embed et objects (vidéos, SVG, PDF, autres pages, etc) etc), rendu un peu plus "chaud", bref, je préfère :) ).
      • [^] # Re: Ha bon?

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

        Mwai, je suis pas très convaincu par tes arguments.

        J'utilise kwebkitpart depuis plusieurs moi, et je vois pas ce qui pourrait me faire retourner sous khtml:

        - Meilleur respect des standards? Je pense pas serieusement que KHTML soit en avance à ce niveau la. Par exemple, je force la taille des polices des pages web, avec KHTML ca ressemble vraiment à rien, avec Webkit, ca passe.

        - Meilleur intégration à KDE ? Avec le travail de adawit, il ne manque vraiment plus grand chose (adblock ?)

        - L'intégration de kpart dans les pages web fonctionne très bien avec kwebkitpart, la critique (sur planetekde) était pour rekonq qui lui pour l'instant ne peut pas les utiliser.

Suivre le flux des commentaires

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