Journal Des nouvelles de Cream-Browser

Posté par David Delassus (site web personnel) le 24 septembre 2011 à 01:11.

Étiquettes :

sept.

2011

Je vous avez déjà parlé de Cream-Browser dans ce journal.

Après 5 long mois je pense qu'il est temps de rédiger un nouvel article pour ceux ayant la flemme de suivre le blog, le flux RSS, la mailing list ou carrément le commit log sur github.

J'avais dans mon dernier article présenté deux caractéristiques de Cream-Browser :

support de GTK+-2.0 et GTK+-3.0
les GModule
la configuration en lua

Quelques petites choses ont changés depuis.

Suppression du support de GTK+-2.0

C'est relativement chiant de maintenir le support pour deux librairies, cela implique d'avoir les deux installées même si au final on en utilise qu'une seule :/

De plus GTK+-3.0 apporte des fonctionnalités fortes intéressantes. Le support de GTK+-2.0 handicape donc le développement sur certains point.

Bref désormais Cream-Browser, c'est full-gtk3

Les GModule remplacés par une interface.

Pour rappel, GModule me permet de charger une librairie dynamique au runtime. J'avais eu dans l'idée de déléguer le support des protocoles à des modules externes, ainsi on ne chargerait pas en mémoire ce dont on ne veut pas.

L'idée est belle, mais pas réalisable. Si le module externe dépend lui même d'une autre librairie dynamique, il faut que Cream-Browser soit lié à cette librairie lors de la compilation. On perd donc totalement l'aspect runtime de la chose.

Donc au lieu de créer un module externe, il s'agit désormais d'un module interne (un simple GObject qui implémente l'interface CreamModule, via cette interface Cream-Browser utilise le module qui est associé à tel ou tel protocole).

La configuration lua

Je tiens à préciser qu'il s'agit ici uniquement de la configuration qui est en lua, pas comme luakit (celui ci se présente sous la forme d'une librairie lua développé en C, le navigateur à proprement parler est donc développé en lua).

Actuellement seul les key-bindings sont fait, je vous invite à voir cette page.

GtkVimSplit

Je suis plutôt fier de cette fonctionnalité (qui a dit auto-satisfaction ?), et je n'ai vu aucun navigateur l'implémenter, je n'ai peut-être pas cherché assez loin.

Vous, linuxiens aguerri, vous connaissez vim, vous connaissez les commandes split et vsplit.

Le GtkVimSplit est un widget de ma création permettant la même chose dans Cream-Browser. Je vous laisse voir le résultat sur la section captures d'écran du wiki.

Après tout, je veux faire un navigateur vim-like, je me devais d'implémenter cette fonctionnalité.

Personnalisation de l'interface via du CSS

C'est une des fonctionnalités de GTK+-3.0 qui m'a séduit : le GtkCssProvider pour charger une feuille de style CSS afin de personnaliser l'apparence des widgets GTK.

On passe donc de ceci :

à ceci :

Ce qu'il reste à faire

Cookies/Session/Favoris/Historique : la base d'un navigateur quoi.
La complétion
Le follow-hint : Essayez de tapez "f" lorsque vous êtes sous Vimperator/Pentadactyl (firefox), vous verrez comme c'est pratique :)
L'API lua : Elle avance, mais il y a encore pas mal de choses à faire dedans.
Un plugin-blocker : Par exemple afficher un bouton "Activer l'animation flash" à la place de l'animation en elle même et l'activer seulement si on clique sur le bouton, le tout scriptable en lua bien sûr.
La finition du module WebKit et le développement de quelques autres ((S)FTP, Gopher, ...)
Et sûrement d'autres choses encore.

Bref j'ai encore du boulot mais j'espère sortir rapidement une release ^^.

Infos supplémentaires

Un canal IRC est ouvert depuis les débuts du projet : #cream-browser @ irc.freenode.net
Le site Internet est disponible à l'adresse suivante : http://cream-browser.net/
Le blog est disponible à l'adresse suivante : http://cream-browser.net/blog/ [RSS]
Les mailing list : devel, users
Le wiki : http://github.com/linkdd/cream-browser/wiki/
Lien sur github : http://github.com/linkdd/cream-browser

# Irrealisable n'est pas Linux

Posté par Ph Husson (site web personnel) le 24 septembre 2011 à 05:50. Évalué à 8.

L'idée est belle, mais pas réalisable. Si le module externe dépend lui même d'une autre librairie dynamique, il faut que Cream-Browser soit lié à cette librairie lors de la compilation. On perd donc totalement l'aspect runtime de la chose.

Euh, sauf contrainte étrange, ce n'est pas un problème du tout. Soit il te manque des flags sur dlopen, soit un -rdynamic, soit tout simplement les dépendances du module au moment du link du .so.
# Tiling browser

Posté par jiyuu le 24 septembre 2011 à 11:30. Évalué à 2.

GtkVimSplit

Je suis plutôt fier de cette fonctionnalité (qui a dit auto-satisfaction ?), et je n'ai vu aucun navigateur
l'implémenter, je n'ai peut-être pas cherché assez loin.

Ce n'est pas exactement pareil mais dwb permet aussi d'afficher plusieurs pages web côte à côte. À la différence de cream-browser, le split est automatique à l'instar des tiling WM tel que dwm dont l'auteur s'est inspiré.
- [^] # Re: Tiling browser
  
  Posté par David Delassus (site web personnel) le 24 septembre 2011 à 12:24. Évalué à 5.
  Oui je connais dwb, justement c'est lui qui m'a donné l'idée d'inventer le split. Car je trouvais malheureux de ne pouvoir redimensionner les vues :)
  
  Dans le concept c'est différent :
  - dwb utilise un GtkPaned, d'un coté on a un WebView, et de l'autre un GtkHBox dans lequel s'empile des WebView
  - Le GtkVimSplit est totalement différent :
    - Au départ c'est un WebView tout bête.
    - On split, le GtkVimSplit devient un GtkPaned, le WebView est déplacé dans un nouveau GtkVimSplit lui même placé dans le GtkPaned et on ouvre un second GtkVimSplit dans la second partie du GtkPaned
    - On resplit, et c'est le GtkVimSplit qui a le focus qui répète l'action
  On pourrait représenter ce schéma par un arbre binaire ou chaque noeud est un GtkPaned, la racine le GtkVimSplit, les feuilles les WebView.
  
  https://link-society.com - https://kubirds.com
- [^] # Re: Tiling browser
  
  Posté par Gabin le 28 septembre 2011 à 17:54. Évalué à 0.
  
  Konqueror le fait depuis belle lurette et avec des trucs intéressants comme le gestionnaire de fichier ou terminal que tu peux embarquer dans la fenêtre du navigateur.
  
  Sinon, bravo pour ton projet, c'est une super initiative, même si je suis assez satisfait de Firefox et Pendactyl je ne suis pas contre un navigateur allégé, basé sur webkit et limité à ce qu'il faut.
  - [^] # Re: Tiling browser
    
    Posté par David Delassus (site web personnel) le 29 septembre 2011 à 02:39. Évalué à 1.
    
    Ah je ne savais pas pour Konqueror, merci de l'info :)
    
    Merci pour le soutiens ^^, ici le but n'est pas de remplacer firefox mais d'implémenter les fonctionnalités les plus intéressante qu'il offre (look vimesque, multi-protocole, profiles, bloqueur de pub/popup/plugins (tel que flashplayer), le tout en natif et simplifié au minimum pour plus de rapidité et de légèreté :)
    
    M'enfin je prévois quand même une gestion des plugins même si je n'ai aucune idée de comment ^^
    
    https://link-society.com - https://kubirds.com
# Gopher

Posté par Marotte ⛧ le 24 septembre 2011 à 16:56. Évalué à 3.

Gopher

Il y a encore des sites utiles et utilisés en Gopher ? Est-ce vraiment nécessaire d'alourdir ton application avec ça ?
- [^] # Re: Gopher
  
  Posté par David Delassus (site web personnel) le 24 septembre 2011 à 19:11. Évalué à 2.
  Sachant que chaque modules peut-être désactivé à la compilation, je pense que cela peut être sympa de l'intégrer.
  
  D'autant plus que Gopher n'est pas si lourd que ça, un simple socket + un ptit GIOChannel (pour l'asynchrone) et c'est réglé.
  
  Par exemple :
```
$ ./configure --enable-mod-webkit --enable-mod-dummy --disable-mod-gopher
```
  https://link-society.com - https://kubirds.com
- [^] # Re: Gopher
  
  Posté par BFG le 24 septembre 2011 à 19:22. Évalué à 4.
  
  Personnellement, j'ai enlevé la touche "Caps Lock" de mon clavier car ça l'alourdissait inutilement.
  - [^] # Re: Gopher
    
    Posté par Marotte ⛧ le 24 septembre 2011 à 20:09. Évalué à 2.
    
    Certes c'est peu d'empreinte mémoire, peu d'espace et c'est une option, mais j'entendais alourdir dans le sens : plus de travail de développement/documentation/support pour pas grand chose.
    
    Il semblerait que Firefox ait arrêté le support de Gopher après la 4.0 et IE après la version 6. Au moins tu vas à contre-courant de certains leaders dans ce domaine, ça c'est plutôt pas mal.
    
    Je suis déçu que personne n'ait répondu à la question : "Qui utilise Gopher ? Pourquoi ?". Je vais être obligé d'aller me renseigner moi même. Vous êtes vraiment pas gentils avec les gros feignants !
    - [^] # Re: Gopher
      
      Posté par CrEv (site web personnel) le 24 septembre 2011 à 22:31. Évalué à 2.
      
      Vous êtes vraiment pas gentils avec les gros feignants !
      
      C'est pas ça. C'est juste que personne utilise Gopher, donc tu ne risques pas d'avoir une réponse...
      - [^] # Re: Gopher
        
        Posté par Marotte ⛧ le 25 septembre 2011 à 05:23. Évalué à 1.
        
        personne utilise Gopher
        
        C'est une réponse :)
        
        C'est vrai que quand on lit ça sur wikipedia :
        
        Gopher users remember the system as being "faster and more efficient and so much more organised" than today's Web services.
        
        C'est du sétémieuavent caractérisé mais ça fait réfléchir.
        
        [^] # Re: Gopher
        
        Posté par Kerro le 25 septembre 2011 à 20:51. Évalué à 5.
        
        Avec des millions de fois moins d'informations à classer, c'est facile d'être mieux organisé.
        
        C'était mieux avant... lorsque le marketing n'envahissait pas le web.
  - [^] # Re: Gopher
    
    Posté par Marotte ⛧ le 24 septembre 2011 à 20:14. Évalué à 2.
# Options

Posté par Marotte ⛧ le 29 septembre 2011 à 02:44. Évalué à 1.

Pour faire suite à ce journal.

Est-ce que tu comptes proposer un moyen de gérer finement les autorisations des cookies et des entêtes HTTP[1] dans ton browser ?

[1] Par exemple, pourquoi ne peut on pas autoriser le HTTP referrer seulement pour les requêtes vers certains sites et pas d'autres ?
- [^] # Re: Options
  
  Posté par David Delassus (site web personnel) le 29 septembre 2011 à 03:19. Évalué à 1.
  J'avais prévu (et je ne sais pas si WebKit, enfin libsoup plutôt me le permettra, je vais potasser les deux) était plutôt simple :
  - On enregistre les cookies pour un domaine, par exemple :
    1. Je visite le site example.domain.com, j'enregistre les cookies au domaine domain.com.
    2. Je visite le site www.domain.com, je lui envoie les cookies enregistrés précédemment, et j'en enregistre de nouveaux, toujours associés au domaine cité.
    3. Je visite le site www.example.fr, je ne lui envoie aucun cookies car il n'y en a aucun enregistré pour example.fr, j'en enregistre pour ce domaine.
    4. Je reviens sur example.domain.com, je lui envoie les cookies enregistré au domaine domain.com mais pas ceux enregistré pour example.fr.
  - L'utilisateur aura (par le biais de la page about:cookies) la possibilité de modifier les cookies (valeur, durée de vie, etc...)
  De plus, je pense que le premier point permettra d'éradiquer la publicité ciblée (qui, il me semble corrigez moi si je me trompe, utilise les cookies pour connaître les sites visités par l'utilisateur et donc ces centres d'intérêts).
  
  J'ai implémenté il y a peu la gestion des profils dans Cream-Browser. (cream-browser -p <profil>). Le profil par défaut est donc "default". Les cookies seront enregistré dans le dossier : ${XDG_CACHE_HOME}/cream-browser/<profil>/cookies/. Donc si on lance deux instances de Cream-Browser sous deux profils différents, on aura ainsi la possibilité d'aller sur le même site sous deux sessions différentes (utile pour le développement de site web) :)
  
  Et il y aura certainement d'autres idées concernant la gestion des cookies qui me viendrons en tête.
  
  NB: Les cookies ne sont pas encore implémenté, je dois d'abord coder la gestion du dossier de cache :p
  
  https://link-society.com - https://kubirds.com

Suivre le flux des commentaires

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