Journal Cream-Browser

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
17
9
avr.
2011

Vous en avez peut-être entendu parler (ou pas). Bref cela ne fait pas de mal de faire une nouvelle présentation n'est-ce pas ?

Un peu d'histoire ? Oula que non c'est barbant je me contenterai simplement d'énoncer tout cela dans les grandes lignes (pas de dates, je m'en souviens plus exactement).

Un petit historique du projet

  • Il y a 1-2 ans : Cream-Browser est un navigateur Internet vim-like développé avec GTK+ et WebKit, la configuration se fait via un fichier de syntaxe INI.
  • Il y a 1 ans (et un peu plus) : Grande pause dans le projet.
  • Peu après : Cream-Browser reprend, beaucoup de modification dans le code. Notamment une architecture un peu plus modulaire pour pouvoir intégrer différents protocoles autres que ceux gérés par WebKit (je pense à FTP et Gopher, cela n'a jamais abouti). La configuration se fait via la libconfuse (une syntaxe plus souple mais pas trop compliquée pour autant).
  • Quelques mois plus tard : Nouvelle pause dans le projet.
  • Il y a quelques mois : Reprise du projet à 0. L'ancienne version toujours disponible dans la branche master (les travaux en cours étant dans la branche unstable). Les nouveautés sont :
    • Configuration en Lua : langage simple, rapide et beaucoup plus souple. Cream-Browser interagit directement avec Lua qui en altère le fonctionnement et vice-versa. La plupart des fonctionnalités ajoutés Cream-Browser se retrouve généralement directement dans Lua
    • Intégration de GModule : J'expliquerai cela dans la suite de ce journal
    • Compatibilité GTK+-3.0 et on tente la portabilité sous Windows (ayeaye je sens le troll :D) grâce à une utilisation massive de la GLib (qui permet de faire à peu près tout).

Pour résumer. Cream-Browser c'est un navigateur Internet (OUI Internet, car je prévois d'intégrer gopher, FTP, SFTP, HTTP, HTTPS, etc. bref cela ne se limitera pas, enfin j'espère, au simple Web).

Actuellement

Actuellement, Cream-Browser se présente un peu plus comme un framework que dans ses débuts.

GModule

Avant, lorsque j'intégrais un nouveau protocole, j'y ajoutais donc un widget GTK dans le code qui s'occupait de charger l'URL demandé et d'afficher le contenu (liste des dossiers pour un FTP, la page web pour WebKit, etc.). Bref vous ne voulez pas de Gopher ? dommage on le charge quand même :(

Maintenant, avec l'intégration de GModule, cela se passe différemment. GModule permet en fait de charger au runtime une bibliothèque (dynamique ou statique, la glib étant portable il peut très bien s'agir d'une dll de Windows, ou de .so/.a sous les UNIX-like). Chaque modules (bibliothèques donc) fournira à Cream-Browser un widget GTK capable de charger l'URL et de l'afficher. Ainsi imaginez donc avoir un module WebKit que vous chargez au lancement de Cream-Browser, vous l'associez au protocole HTTP/HTTPS et vous voila apte à charger toutes URL http:// et https://. Vous ne souhaitez pas intégrer gopher, il vous suffira de ne pas charger le module.

Le chargement des modules (et l'association au protocole géré par ce dernier) se fera donc via la configuration en Lua (ne vous inquiétez pas, rien de bien compliqué car la bibliothèque Lua se chargera de cela à votre place bien qu'il ne vous sera pas impossible de le faire vous même).

Ainsi, celui qui désire utiliser Gecko au lieu de WebKit pourra, à condition qu'il existe un module pour.
Vous avez sûrement vu sur des sites tels que ubuntu-fr.org une URL du type apt://paquet. Si un module existe pour ce protocole, il sera donc possible de l'utiliser.

Attention: Cream-Browser sera toujours développé dans l'optique d'être un navigateur Internet. Développer des modules pour des utilisations autres (terminaux, édition de texte, etc.) le rendra anti-productif. Cream-Browser ne se veut pas un emacs-like (non nous ne sommes pas vendredi donc je m’arrêterai la sur ce point).

Lua

Comme dit plus haut, la configuration se fera désormais en Lua. Cela permettra une meilleure souplesse du navigateur grâce aux atouts de Lua.

En effet, dans une précédente version je désirais gérer les UserAgent dynamiques (associer un UserAgent pour un nom de domaine). Pour se faire j'ai du coder cela en C. C'est désormais faisable directement en Lua !

Je vise toujours la configuration simple ET souple. Lua n'étant pas compliqué, il suffira de lire le fichier de configuration pour le comprendre aisément, différents exemples de configurations seront postés sur le site.

Une API C est donc fournie à Lua, API qui sera utilisée par une bibliothèque Lua (require("cream")). Cream-Browser interagira donc directement avec Lua, et le fonctionnement du script dépendra du fonctionnement de Cream-Browser (et vice-versa). L'évolution (implémentation de nouvelle fonctionnalité, correction de bug...) de l'un entraînera forcément l'évolution de l'autre.

Infos supplémentaires

  • # uzbl

    Posté par  . Évalué à 5.

    Dans l'idée, ça me rappelle un peu uzbl, le côté script poilu en moins.

    Sinon, tu as pensé à regarder du côté de libpeas pour les fonctions "sympas mais qui donnent les fesses lourdes" (aka plugins) à activer par l'utilisateur s'il trouve ça bien ?

    • [^] # Re: uzbl (ou luakit)

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

      C'est plus proche de luakit à priori.

      Luakit lui ne fait que du web, mais il le fait pas mal. Le seul manque actuel c'est l'édition des textarea qui pourrait se faire dans vim car depuis la dernière version il y a une gestion des bookmarks, de l'historique de navigation et des téléchargements (j'en passe probablement).

      Pour l'instant c'est mon navigateur par défaut, et je ne regrette pas le changement.

      • [^] # Re: uzbl (ou luakit)

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

        J'aime aussi beaucoup luakit. Jusqu'à la sortie de firefox4, c'était mon navigateur par défaut. Dans les features récentes, il y a aussi le gestionnaire de mots de passe.

        Par contre, il a des lenteurs de temps en temps : quand une page met du temps à charger, la barre de commande est lente à apparaître et réagir ; certains sites sont aussi à la traine par rapport à chromium, firefox, opera (google reader, linuxfr pour les pages contenant beaucoup de commentaires, lefigaro par exemple).

        Mais dans la famille uzbl, jumanji, luakit, c'est celui que je préfère. Il faut que j'essaie cream-browser maintenant !

        • [^] # Re: uzbl (ou luakit)

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

          Il faut que j'essaie cream-browser maintenant !

          Tatata! La branche unstable comme son nom l'indique n'est pas stable ni utilisable :) Je vous inviterai à tester cela lorsque tout sera passé dans master :)

          https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

          • [^] # Re: uzbl (ou luakit)

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

            C'est pas très malin tout de même de présenter un projet inutilisable … Il aurait mieux valu attendre la sortie d'une version stable.

            Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

            • [^] # Re: uzbl (ou luakit)

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

              Je souhaite en fait faire part dans mes journaux (car d'autres viendront) de l'avancement du projet. Sachant que je code en ce moment la GUI, d'ici un mois ou deux (si tout se passe bien), une version utilisable devrait être disponible.

              https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

      • [^] # Re: uzbl (ou luakit)

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

        Je pense que le seul point commun entre luakit et Cream-Browser sera la configuration en Lua :)

        Il est vrai cependant que c'est un bon navigateur (et j'en ai testé pas mal, prenez dwb par exemple qui permet le tiling).

        https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

        • [^] # Re: uzbl (ou luakit)

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

          J'ai aussi testé dwb, mais je lui préfère luakit. Dwb n'es pas encore tout à fait stable et à un problème d'encodage assez casse-pieds. Quand au tiling, c'est sympa mais c'est plutôt au gestionnaire de fenêtre de faire ça.

          Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

          • [^] # Re: uzbl (ou luakit)

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

            Je ne peux que plussoyer. J'ai pu observer dans les derniers commit un ralentissement global du navigateur (par exemple un petit freeze de quelques secondes quand une page bourré de flash/javascript charge, I hate popup).

            https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

    • [^] # Re: uzbl

      Posté par  . Évalué à 6.

      ça me rappelle un peu uzbl, le côté script poilu nom imprononçable en moins.

      • [^] # Re: uzbl

        Posté par  . Évalué à 4.

        À le prononcer ("Yuu zé beu le" aka "usable") ou à le lire ?

        • [^] # Re: uzbl

          Posté par  . Évalué à 6.

          On croirait lire du Shadok : Ga Bu Zo Meu !

          • [^] # Re: uzbl

            Posté par  . Évalué à 3.

            En dehors de l'aspect trollesque, savez-vous pourquoi tout ces navigateurs alternatifs sont en gtkxx et qu'aucun ou presque (comme reconq) ne soit en qt ?

            Est-ce le résultat de la grosse utilisation de distribution *buntu ?

            Oui, pourquoi, toi le développeur barbu tu veux toujours coder tes interfaces en autre chose que qt ?
            En faite ma réflexion, serait presque, pourquoi le projet alternatif utilise du gtk alagnome et pas du qtalakde ?

            • [^] # Re: uzbl

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

              Et tu oublis Arora qui est également développé à l'aide de Qt, http://code.google.com/p/arora/

              La réponse est bien plus simple qu'un débat GNOME/KDE.
              A ma connaissance Qt n'est disponible que pour le C++, or je préfère nettement le C.
              Ce n'est qu'une question de goûts. :)

              Après l'utilisation plus généralisée de GTK+ est due, à mon avis, à la fausse idée que GTK+ est plus léger que Qt, je pense que cela n'est pas comparable car GTK+ est une librairie graphique là où Qt est un framework. Tout ce que propose GTK+ et la GLib et autres librairies tierces sont disponibles dans Qt, comparer QtGui et GTK+ serait plus raisonnable mais je ne connais pas le verdict ^^

              https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

            • [^] # Re: uzbl

              Posté par  . Évalué à 4.

              En dehors de l'aspect trollesque, savez-vous pourquoi tout ces navigateurs alternatifs sont en gtkxx et qu'aucun ou presque (comme reconq) ne soit en qt ?

              Ils sont tous en C, et pour rester dans le domaine du troll, ils proposent tous des raccourcis type vi et aucun des raccourcis type emacs !

              • [^] # Re: uzbl

                Posté par  . Évalué à 1.

                Normal, les raccourcis type Emacs sur autre chose qu'Emacs n'intéressent pas les utilisateurs d'Emacs qui ne font tourner rien d'autre sur leur système.

  • # Cream Desktop Environment

    Posté par  . Évalué à 2.

    Vu qu'il n'en est pas fait mention, je suppose que Cream-Browser n'a aucun lien avec Cream Desktop Environment autre que le nom Cream ?

Suivre le flux des commentaires

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