Journal avenir de konqueror et khtml dans KDE ?

Posté par  .
Étiquettes :
28
1
juin
2012

Salut à tous,

J'utilise KDE et konqueror depuis plusieurs années maintenant. Mais de plus en plus de site web passent très mal ou pas du tout… Il semble que KHTML ait beaucoup de mal avec les nouveautés genre HTML 5, la vieillesse commence à se faire sentir :-(

Konqueror n'est pas le seul navigateur utilisable sous KDE, il existe :
– firefox, qui n'est pas franchement dans une logique d'intégration…
– arora, qui est plutôt tourné Qt que KDE ;
– rekonq qui est vraiment bien, mais qui possède à mes yeux certains inconvénients majeurs, comme par exemple de ne pas utiliser les applications dédiées pour ouvrir les documents (kwrite, calligra, okular, etc) mais de tout mettre dans une kpart.
– konqueror + kpart webkit, qui tourne plutôt très bien

D'où mon interogation : est-ce qu'il est prévu dans les prochains KDE de garde konqueror + khtml comme navigateur web par défaut, ou d'opérer une autre stratégie ?

Amis KDEistes, si vous avez des informations, merci de les partager !

  • # .

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

    pour rekonq, il utilise la kpart correcte, non ? (par exemple il ouvre ton pdf dans la kpart okular) Si oui, alors je trouve ça bien, surtout mieux que d'intégrer des visionneuses comme c'est le cas dans chrome. Autant appeler la vrai application. Après, que ce soit une kpart ou une application dédiée, perso j'aime bien que ça s'ouvre par défaut dans mon navigateur et si j'ai envie dans l'application entière.

    Mais, sans avoir d'info, pour moi le plus logique serait soit konqueror/webkit soit rekonq.
    Dans tous les cas du webkit, je pense que, comme tu l'indique, khtml est un peu trop à la traine. Et passer sur webkit reste une suite logique puisque étant initialement basé sur khtml.
    Par contre, avec quel moteur js ? Car kjs souffre surement également de problèmes de vitesse, mais webkit n'est que le rendu, pas le js. Si konqueror utilisait webkit et v8 ça ferait un bon chois je trouve : performances, plateforme bien connue et utilisée maintenant (donc pas trop de problèmes de support de sites) mais une bien meilleur intégration que chrome/chromium.

    • [^] # Re: .

      Posté par  . Évalué à 2.

      Après, que ce soit une kpart ou une application dédiée, perso j'aime bien que ça s'ouvre par défaut dans mon navigateur et si j'ai envie dans l'application entière.

      Perso je n'aime pas du tout ce comportement : la kpart est bien souvent plus limitée que l'applications. Par exemple il n'y a pas longtemps il n'était pas possible d'imprimer un PDF depuis rekonq, parce que le menu n'était pas disponible… Autre exemple, j'ouvre un fichier texte, ctrl+F pour rechercher du texte… ah ben non, le raccourci est ambigüe.

      Plus généralement, chaque application a développée un environnement adapté (menu, agencement, raccourci clavier, etc.) pour le type de fichier utilisé, je trouve donc dommage de s'en passer.

      • [^] # Re: .

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 01 juin 2012 à 22:20.

        Ce comportement m'em*****ait pour les PDF, qui s'ouvraient en kpart (et que par habitude je refermais en fermant la fenêtre), et ça se configure pour qu'il lance directement l'application.

        Dans la configuration d'association des fichiers (via le paneau de config de Kde ou via les prefs de Konqueror), clic sur Applications, et sur la droite tu peux choisir d'utiliser l'afficheur intégré ou bien l'application hors de Konqueror.
        Sinon, tu peux régler par type de fichier: choisir pdf, ça donne deux onglets, un "Général" (qui chez moi affiche Okular) et un "Intégration" dans lequel tu fixe tes préférences.

        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

        • [^] # Re: .

          Posté par  . Évalué à 2.

          rekonq ne semble pas tenir compte de ce paramètre, malheureusement…

          • [^] # Re: .

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

            Rapport de bug / demande de fonctionnalité…

            Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

    • [^] # Re: .

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

      WebKit est un moteur complet: rendu HTML (WebCore) + interpréteur Javascript (JavaScriptCore) :
      http://trac.webkit.org/wiki/JavaScriptCore

      Chez Google, ils ont effectivement remplacé JavaScriptCore par V8 pour Chrome tout en conservant WebCore

      • [^] # Re: .

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

        Ha oki, merci de la précision. JavaScriptCore est-il dérivé de kjs ?

        • [^] # Re: .

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

          Oui, KJS est bien son ancêtre. Mais je pense qu'ils n'ont plus grand chose en commun.
          Le découpage entre WebCore et JavaScriptCore doit être bien fait pour qu'il soit possible de changer d'interpréteur javascript.

  • # sur userbase

    Posté par  . Évalué à 5.

    Il y a une petite note à ce sujet sur userbase:
    http://userbase.kde.org/Konqueror#KHTML_vs._Webkit

  • # Évolutions de KHTML et Webkit

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

    KHTML n'est pas mort, il continue d'évoluer un petit peu.
    On peut voir l'activité du dévelopement sur ce blog nommé pour l'occasion « KHTML is still alive! » (KHTML est toujours vivant) [1].
    Les commits de KHTML concernent principalement des corrections de bugs.
    Il n'y a malheureusement pas beaucoup d'évolution, mais ça fait toujours plaisir de voir que KHTML n'est pas complètement abandonné.

    Du côté de KJS, ça évolue un peu plus.
    Des développeurs travaillent sur la mise en conformité de KJS avec les tests ecmascript [2].
    On peut également voir un bon nombre de patchs pour KJS sur la Review Board de KDE [3].
    L'implémention Javascript de KJS continue donc de s'améliorer et c'est une bonne chose je pense car KJS est à mon avis le point faible du couple KHTML/KJS.

    Du côté de QtWebkit, les choses vont sûrement évoluer avec l'arrivée de Qt 5.
    Le QtWebkit de Qt 5 utilisera V8 (le moteur Javascript de Chromium/Chrome) [4] et ceci va sûrement donner un bon coup de boost à la KWebkitPart.

    Konqueror est mon navigateur favori et c'est mon navigateur principal.
    Il est léger et très bien intégré à l'environnement KDE.
    J'espère donc qu'il va continuer d'évoluer au niveau de ses moteurs HTML et Javascript.

    [1] http://khtml-konqueror.blogspot.fr/
    [2] http://buschinski.de/2012/02/yay-for-kjskhtml/
    [3] https://git.reviewboard.kde.org/groups/kdelibs/
    [4] http://trac.webkit.org/wiki/QtWebKitForQt5

    • [^] # Re: Évolutions de KHTML et Webkit

      Posté par  . Évalué à 3.

      Oui mais avec un tel écart dans les moyens, on risque fort d'avoir un gros décrochage entre Webkit et KHTML/KJS au niveau des fonctionnalités et des performances? Et l'implémentation des "nouvelles" CSS peut-elle aller assez vite également?

      Peut-être que plein de monde s'en fout parce que "ça va assez vite comma ça!", mais la tendance semble aller vers du js de plus en plus gras. Ce n'est pas pour rien que Google a mis autant de moyen pour avoir un V8 rapide!

      • [^] # Re: Évolutions de KHTML et Webkit

        Posté par  . Évalué à 2.

        Il y en a effet un risque, surtout au niveau du moteur JavaScript, pour les sites-applications et autres précurseurs usant de dizaines de milliers de lignes de code JS (mais là est de pouvoir utiliser conjointement webkit).

        En revanche, concernant les normes HTML5 et CSS3, si les navigateurs jouent à celui qui implémentera un maximum de choses le plus vite, il ne faut pas oublier que le tout n'est grosso modo encore qu'une somme de brouillons soumis à changements. Il peut se passer encore des années avant que ces normes soient finalisées, peut-être assez pour que KHTML reste dans la course, même avec une équipe réduite ?

  • # Je préfère KHTML

    Posté par  . Évalué à 3.

    Moi aussi Konqueror c'est mon navigateur principal, et l'application que je utilise de plus dans la journée. Je préfère le moteur KHTML parce que c'est le plus fiable au niveau de respect des normes HTML, l'aspect des pages (surtout les polices), la correction orthographique.

    C'est bien d'avoir webkit parce que son développement est beaucoup plus important que KHTML mais pour le kde c’est un avantage de pouvoir adapter le moteur de recherche à son environnement et de pouvoir corriger de bug sans attendre les développeurs de webkit réagir (il ne faut pas oublier que les développeur de webkit ne sont pas très coopératifs).

    • [^] # Re: Je préfère KHTML

      Posté par  . Évalué à 3.

      Je préfère le moteur KHTML parce que c'est le plus fiable au niveau de respect des normes HTML

      Tu as une source ? Parce qu'il me semblait qu'au contraire, Webkit est actuellement le moteur le plus respectueux des normes.

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

      • [^] # Re: Je préfère KHTML

        Posté par  . Évalué à 0.

        Je n'ai pas des sources maintenant, il faudra que je cherche des discussions qui disent que khtml, et le moteur de opera, sont les seules qui respect les standard w3c css et souvent c'est sont les sites qui font leur «loi» parce que les autres moteurs bien qu' ils ne respects pas les standards restent plus compatibles que le moteur de konqueror.
        Je pense que ces discussions sont connus depuis longtemps la. Par contre dernièrement konqueror est un peu en retard mais il va récupérer.

  • # KHTML

    Posté par  . Évalué à -7.

    – firefox, qui n'est pas franchement dans une logique d'intégration…

    J’ose même plus en parler de ce navigateur tellement je peux pas le voir.

    – arora, qui est plutôt tourné Qt que KDE ;

    Alors, premièrement, Qt s’adapte très bien à KDE et secondement, Arora n’est plus maintenu depuis environ un an.

    Sur ma distro, suite aux différentes mises à jour de Qt et QtWebkit, il segfault lorsque tu ferme un onglet qui génère du trafic (typiquement, un onglet qui n’a pas fini de charger ou un onglet dont la page fait de l’AJAX).

    – rekonq qui est vraiment bien, mais qui possède à mes yeux certains inconvénients majeurs, comme par exemple de ne pas utiliser les applications dédiées pour ouvrir les documents (kwrite, calligra, okular, etc) mais de tout mettre dans une kpart.

    Son problème c’est qu’il essaye de se la jouer Chromiofox (donc il essaye d’être dégueulasse) sauf qu’il n’y a pas autant de monde pour développer et donc, ça donne rien.

    – konqueror + kpart webkit, qui tourne plutôt très bien

    Konqueror perd les trois quarts de ses fonctionnalités intéressantes avec KPart-WebKit. Pour n’en citer que deux :

    • plus de gestion du javascript par whitelists ;
    • plus de gestion des cookies par whitelists.

    Bref, Konqueror-KHTML reste le meilleur navigatueur qui existe aujourd’hui. Il lui manque une seule et unique chose : des moyens (humains) pour évoluer !

    Amis KDEistes, si vous avez des informations, merci de les partager !

    Je ne suis pas KDEiste, parce que j’aime avoir mon système propre. J’utilise principalement Openbox et des application desktop-free (en général, j’évite GTK comme la peste). Il me manque deux « alternatives » : un lecteur de PDF (xpdf est une merde) et un navigateur web (arora est une merde également).

    • [^] # Re: KHTML

      Posté par  . Évalué à 1.

      Il me manque deux « alternatives » : un lecteur de PDF […] et un navigateur web […].

      As-tu regardé ici ?

  • # un truc de super avec konqueror

    Posté par  . Évalué à 5.

    c'est la possibilité d´archiver les pages web (format .war) malheureusement cette fonctionnalité n'existe et ne fonctionne qu'avec konqueror.

    • [^] # Re: un truc de super avec konqueror

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

      C'est à dire ? Enfin ce que je veux dire c'est en quoi ça diffère des autres navigateurs qui permettent tous d'enregistrer les pages web avec leurs ressources ?
      Et bon, c'est quand même bien con d'utiliser une extension .war qui est par ailleurs déjà utilisée…

      • [^] # Re: un truc de super avec konqueror

        Posté par  . Évalué à 3.

        c'est juste un seul fichier. Pour l'extension je ne sais pas ce qui utilise cela en premier mais le pourquoi c'est "Web ARchive" en meme temps c'est un detail par contre que rekonq soit incapable d'ouvrir le fichier c'est pénible.

      • [^] # Re: un truc de super avec konqueror

        Posté par  . Évalué à 4.

        Et bon, c'est quand même bien con d'utiliser une extension .war qui est par ailleurs déjà utilisée…

        Je ne sais pas à quand remonte son utilisation par konqueror mais ça existait déjà dans 3.5. Il est possible que konqueror l'ait utilisé avant que l'utilisation de .war de Sun soit répandue.

        « 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: un truc de super avec konqueror

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

          La version 3 de kde est sortie en 2002 (et la 3.5 en 2005). La version 1.4 de java (je crois que les war ont étés introduits à partir de ce moment, mais pas certains que ce ne soit pas avant) est sortie en 2002 (avant kde).
          Mais surtout, entre les deux, question usage répandu, y'a franchement pas photo ça c'est certain.

          • [^] # Re: un truc de super avec konqueror

            Posté par  . Évalué à 3.

            Mais je n'ai aucune idée depuis quand c'est dans KDE, ça date peut-être d'avant KDE 3 (en tout cas certainement avant 3.5) mais je ne trouve pas de trace plus précise.

            « 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: un truc de super avec konqueror

      Posté par  . Évalué à 3.

      Un autre truc de super que j'aime avec konqueror c’est la possibilité de découper la page en plusieurs affichages, comme ca on peut regarder en même temps deux pages internet, une autre affichage pour le gestionnaire de fichiers, une autre pour le FTP, le terminal, etc, et travailler simultanément avec toutes les affichages! Aucun autre navigateur n' a pas cette fonctionnalité importante.

    • [^] # Re: un truc de super avec konqueror

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

      Opera, Chrome et IE le permettent, au format MHTML (grosso modo un fichier avec plusieurs fichiers à l'intérieur en utilisant les mime-parts comme les mails), qui est un standard (RFC 2557).

      Bizarrement c'est le libre qui adopte des trucs pas standards (WAR pour Konqueror, MAFF pour Firefox, bug existant pour le support de MHTML depuis 1999, patchs existants et comme d'hab ignorés). Bon OK y'a aussi Safari (webarchive) mais ça compte pas, Apple ils ont toujours été forts pour rien faire comme tout le monde.

      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

  • # khtml + flash

    Posté par  . Évalué à 3.

    autre question : vous arrivez à lire des vidéos flash (youtube par ex.) avec konqueror ? chez moi khtml + flash ne marche pas, mais webkit + flash fonctionne.

Suivre le flux des commentaires

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