Bonjour ,

Nous sommes en décembre, et tout site qui se respecte change de design .

Cette année, je vous ai fait un design spécial pour Noël, disponible sur la page de changement de design. Il vous suffit de choisir le design «Noël» pour profiter de ce nouveau visage du site .

Ok, ce n'est pas le plus beau des designs, mais c'est toujours une bonne chose .

Joyeux Noël .

Bonjour ,

J'en avais parlé il y a quelque temps, et voici qui a été fait : Panache est entièrement documenté en Doxygen. Ainsi, il est très facile d'apprendre comment Panache fonctionne en utilisant une documentation proche de celle de Qt

Qu'est-ce que Doxygen

Doxygen est un programme qui lit des fichiers sources, et génère de la documentation. La documentation étant intégrée dans les sources, il est très facile pour les développeurs de l'adapter dès qu'ils le souhaitent.

De plus, Doxygen s'occupe lui-même de beaucoup de choses, comme la mise en page (titres), et surtout de la génération de très beaux graphiques, histoire de bien se représenter un objet, ou une fonction .

Voici un exemple de fichier documenté en utilisant Doxygen :

Code : cpp

Accéder au site de Doxygen

La documentation de Panache

Ceux qui parcourent de temps en temps le SVN de Logram savent que cela fait déjà longtemps que Panache est documenté. Par contre, ce n'est que maintenant que tous les fichiers de Panache le sont.

Au début, je n'avais fait ça que pour tester Doxygen, mais maintenant, j'ai beaucoup plus documenté. Alors qu'auparavant, seules les fonctions publiques jouissaient d'une documentation, les fonctions privées et protégées, ainsi que les slots, sont maintenant documentés.

Je vous laisse découvrir le fruit de tout ça par vous-même (la page d'accueil n'est pas encore remplie, cliquez sur le menu Classes pour accéder à la documentation) :

Accéder à la documentation de Panache

Bonne découverte de cet outil merveilleux qu'est Panache Doxygen .

Bonjour ,

Panache a bien grandi ces derniers jours, et devient utilisable, tant pour le programmeur (qui peut créer des plugins pour Panache) que pour l'utilisateur, qui a enfin un environnement plus ou moins propre.

Si vous voulez m'aider dans le développement de Panache, je vous invite donc à lire ce tutoriel, pour que vous puissiez faire tous les plugins que vous voulez (menus des applications, configuration, météo, fortunes (blagues), flux RSS, etc). Le système de plugins de Panache est tout ce qui a de plus simple, profitez-en .

Je vous met quand-même la TODO-List de Panache, si jamais vous vous ennuyez, et que vous êtes fort en C++/Qt :

• Amélioration des onglets : on ne peut pas encore les déplacer, et encore moins les cliquer-glisser sur d'autres bords de l'écran.
• Une gestion du bureau proprement dit : affichage du wallpaper, des icônes de programmes, des fichiers/dossiers placés sur le bureau, etc.
• Optimisation : je n'ai pas trop fait attention aux fuites de mémoire, il doit donc y en avoir beaucoup .
• Création de plugins en tous genres, voir plus haut.

Si vous voulez m'aider dans Logram en général, codez de petites applications : éditeur de texte (bon, il y en a déjà 2-3 dessus ), explorateur de fichiers, visionneur d'images, jeux, etc.

Je vous met un screen du tuto sur les plugins de Panache, pour que vous puissiez voir à quel point il est souple :

A plus, et bon développement .

Bonjour,

Enfin un peu d'organisation, et un peu d'avancées .

Cela fait 3 jours que j'essaye de vous conconcter une distribution de base pour Logram, contenant un minimum de paquets, et correctement configurée. Je voulais me baser sur LFS, mais c'est trop difficile à gérer.

Logram est donc basé sur Debian, pour le moment. La seule chose qu'il utilisera au final de Debian est le gestionnaire de paquets APT, qui est remarquablement bien fait. Pour le moment, tous les paquets de Logram sont des paquets de Debian, mais au fur et à mesure qu'on développera nos propres paquets, ils s'ajouterons aux paquets Debian, ce qui fait que Logram sera de plus en plus Logrammien, tout en bénéficiant du travail de l'équipe de Debian, c'est à dire les correctifs de sécurité, et surtout de stabilité .

Passons aux choses sérieuses, téléchargeons Logram. Le fichier logram.tar.bz2 (232,7 Mio) est diponible ici :

Télécharger Logram Debian-Based

Installation de Logram

Je n'ai pas pu vous faire un LiveCD, pour la simple et bonne raison qu'un LiveCD est tout de suite beaucoup plus lourd. Le fichier que vous téléchargez est une image disque de Logram.

Pour installer Logram, voici la marche à suivre :

• Téléchargez le fichier
• Partitionnez votre disque pour créer une partition réservée à Logram, de minimum 1Gio (Logram est amené à grossir)
• Formatez cette partition en ext3, ext2, ou ReiserFS
• Montez cette partition
• Décompactez l'archive en root !, par un simple tar -xf logram.tar.bz2.
• Copiez ce que vous avez décompressé sur la partition avec la commande cp -ar, c'est très important, car il faut absolument garder les liens symboliques
• Les fichiers décompressés ne doivent presque pas être retouchés.
• Fusionnez le contenu du dossier logram_debianbased/boot (pas les sous-dossiers) avec votre dossier boot habituel.
• Editez votre menu.lst pour ajouter une ligne qui permet de démarrer le noyau Logram placé dans votre dossier boot (Logram fourni un petit fichier menu.lst, qui comprend les enregistrements nécessaires à ajouter dans le vôtre. Changez la ligne root (xxx) en dessous de title Debian... pour qu'elle soit comme celle de vos autres entrées, et changez l'argument root du noyau pour qu'il pointe vers la partition sur laquelle vous avez installé Logram)
• Redémarrez, tout devrait normalement marcher

Si vous avez des problèmes, faites-en part sur les commentaires .

Utiliser Logram

Si jamais vous redémarrez, et que vous tombez sur "localhost login :", c'est que vous avez tout réussi. L'utilisateur root n'a pas de mot de passe, c'est à vous de lui en donner un. Un utilisateur normal, nommé logram a le mot de passe azertyuiop. Utilisez-le si vous ne voulez pas toucher au système.

Dans le dossier /home/logram se trouve un fichier README.txt, qui explique comment se servir de Logram. Vous avez deux sous-dossiers : svn_anonyme qui contient les versions SVN de quelques applications Logram (juste Panache pour le moment), et zNavigo qui contient le navigateur web des zéros (léger, rapide, et codé avec Qt).

Gérer le système

Vous êtes sur un système Debian de base, mais correctement configuré. Vous disposez d'un serveur X11 complet, avec la majorité des pilotes vidéo, ainsi que de tout ce qu'il faut pour développer avec Qt : build-essentials et libqt4-dev . Vous pouvez directement commencer à coder.

Remarquez simplement que Debian, comme Ubuntu Ubuntu, comme Debian, fourni le programme apt-get qui vous permet de très facilement ajouter de nouveaux paquets à votre système.

Abandonner la console, passer en mode graphique

Logram est bien sûr déjà utilisable en mode graphique . Pour cela, suivez les étapes suivantes. après chaque commande se terminant par #, remplacez le # par &. C'est un bug du lCode.

Code : console
Voilà, vous vous retrouvez avec un Panache lancé, avec deux onglets dedans : zNavigo (ouvert sur la page du SdZ ) et une console xTerm, pour vous permettre de gérer le système avec zNavigo ouvert à côté .

Bon dév .

Bonjour ,

J'ai une bonne nouvelle à vous annoncer : Panache, le décorateur de fenêtres, a fait son apparition dans les dépôts SVN. Il a en fait atteint une certaine maturité (on peut l'utiliser maintenant), et je laisse donc tous les intéressés lire son code source et le modifier.

Si vous modifiez Panache, le mieux est de me faire parvenir par MP une nouvelle archive panache.tar.bz2, pour que je puisse juger de vos modifications, et les intégrer dans le SVN. Si vraiment vous avez bien travaillé, je pourrais envisager de vous donner un accès en écriture au SVN de Logram .

Ce qu'il reste à faire dans Panache

Panache est utilisable : bonne nouvelle. Cela veut dire que vous pouvez dors et déjà commencer à coder vos propres petites applications pour Logram, avec Qt.

Voici la liste des choses qu'il faudrait encore intégrer dans Panache :

• La correction de quelques petits bugs, et l'amélioration générale des sources (je les ai tappée un peu vite, il reste encore quelques messages de débogage, des commentaires mal formés, etc).
• La gestion d'un fichier de configuration pour un peu de tout, comme l'organisation des onglets (en haut, en bas, une taille maximale pour le titre, etc), ou les couleurs/transparence utilisées par les décorations de boîte de dialogue (une liste de TODO: dans Tab.cpp )
• Le menu général, qui permettera de lancer de nouvelles applications, car pour le moment, GNOME doit encore être lancé pour avoir l'onglet x-nautilus-desktop (icônes du bureau) et les Panel supérieur et inférieur de l'écran GNOME.
• L'application annexe qui s'occupe d'afficher le premier onglet au démarrage, Bureau, et qui affichera le papier peint ainsi que les icônes.
• La gestion du cliquer-glisser pour les onglets, pour pouvoir créer un nouveau groupe d'onglet. Tout est déjà en place : la collection Workspaces dans FenPrincipale, le QGridLayout pour positionner les Workspaces, etc
• Une amélioration de la gestion des fenêtres en général, en particulier une meilleure détection des boîtes de dialogue, etc

En clair, il reste encore beaucoup de choses .

A plus.

Bonjour,

Je vous rassure, pas de mauvaises nouvelles ici .

Ca fait quelques jours que je travaille aux Llibs (avec l'aide de Malgon ), et je me pose une question fondamentale, difficile, ou plutôt des questions : Qt or not ? X11 or not ?

L'idée de départ est de créer les Llibs, et je vous rassure, on créera toujours les Llibs, aussi complètes que possible .

Il y a seulement un problème, et pas des moindres : l'interface graphique, et surtout la compatibilité. L'idée principale était d'utiliser le framebuffer, mais je me suis rendu compte de quelque chose : si on utilise le framebuffer, aucune application, Windows ou Linux ne sera compatible pour la simple et bonne raison que les applis Linux utilisent X11, ainsi que Wine.

Il semblerait donc qu'il faille utiliser X11, mais alors, vas-t-on recréer une lib graphique qui utilise les Xlibs (librairies de X11), ou allons-nous utiliser Qt qui est très puissant et très complet, ou GTK qui est léger et performant ?

Je résume les avantages et inconvénients à utiliser X11 avec une librairie :

X11 avec Qt ou GTK

Le choix le plus simple, mais où on travaille le moins, quoiqu'il faut encore faire beaucoup de choses, comme l'intégration de Qt/GTK dans les Llibs, et le reste des Llibs (pour qu'on n'aie pas à utiliser des librairies annexes pour créer de bonnes applications, les Llibs ne seront jamais abandonnées).

Avantages

• On installe X11 et Qt, et on peut commencer à développer. Mieux encore : vous pourrez développer confortablement sous votre Linux, directement dans Code::Blocks, en utilisant Qt ou GTK (je vous laisse le choix de la lib). Même les Llibs pourront êtres développées dans ce cadre magnifique
• La puissance est au rendez-vous : on a la vitesse de X11 (qui utilise l'accélération matérielle, même si X11 est assez lourd) avec la puissance de Qt (on peut facilement faire de très belles et puissantes applications)

Inconvénients

• On pourrait nous prendre pour des flemmards, car une bonne partie des choses est déjà faite, mais marche.

Conclusion

Une bonne solution à priori, car on pourra développer des applications OpenGL, utiliser tout Qt, développer confortablement sur son Linux, etc.

De plus, le plus intéressant reste à faire : les Llibs, qui se concentreraient justement sur le défaut de Linux : l'éclatement des librairies. Par exemple, une partie des Llibs déjà faite est la gestion des fichiers .conf, chose inexistante autre part sans le coder soi-même dans une librairie statique, ou directement dans l'application.

Qt/GTK avec notre propre interface graphique

Ici, c'est entre les deux, et je vous dis tout de suite que cette solution ne me plaît pas, vous allez voir pourquoi .

Avantages

• On a la puissance de Qt accessible, et on est compatibles avec les applications Qt existantes, nécessitant une simple recompilation
• Ceux qui aiment voir les gens travailler ( ) vont être content, car on doit tout refaire également. De plus, on pourrait plus facilement intégrer les bonnes choses de Logram, comme les onglets, etc, quoique c'est aussi possible avec X11

Inconvénients

• On utilise Qt, donc on ne refait pas tout (quoique ça peut être un avantage)
• On n'est compatible avec rien, comme avec le noyau Logram : une application GTK ne trouvera pas X et plantera, une Qt normal aussi, une wxWidget aussi, une Java aussi, et Wine ne marchera pas, car X11 est une brique très importante

Conclusion

Je vous propose tout de même la solution, même si je la trouve très mauvaise.

Les Llibs pures

Solution intermédiaire, elle a son charme, même si on risque de ne jamais pouvoir utiliser Logram, ou en tous cas, on aura un gros problèmes de compatibilité et de manque de performances.

Avantages

• On crée tout nous-même, on obtient alors un système léger et "Logrammien", entièrement fait par l'équipe

Inconvénients

• Comme plus haut, sans serveur X, on est compatibles avec rien
• On risque de se retrouver avec quelque chose qui marche, et on voudra porter les applications qui nous tiennent à coeur. A ce moment là, on va se frotter à un gros problème : le manque de fonctionnalités, car on n'aura pas réussi à implémenter tout ce qu'on veut, et on n'aura peut-être même pas imaginé qu'une certaine fonctionnalité existe.

Le mot de la fin

Je vous laisse choisir et débattre (intelligemment) sur les commentaires de news. Si une idée ne plaît pas à quelqu'un, inutile de menacer de quitter l'équipe . Discutez-en simplement calmement, car pensez à une chose : «Les absents ont tors», autrement dit, si vous êtes contre une idée, et que vous quittez Logram, c'est une voie en moins contre cette idée. Je dis ça juste comme ça, pour que vous ayez toutes les cartes en main .

Bon débat, à nouveau (on débat souvent pour le moment).

Bonjour ,

J'ai une grande nouvelle, ou plutôt deux grandes nouvelles à vous annoncer.

Logram est enfin plus ou moins organisé

Jettez un oeil au tuto coup de coeur : il a changé !

Le tuto coup de coeur du moment est le tuto qui explique comment programmer pour Logram, ou comment programmer Logram tout court. C'est un tuto que j'ai commencé à rédiger il y a quelques jours, et qui est normalement acceptable. Si vous constatez qu'il y a des erreurs ou des imperfections, créez un topic qui les rescence dans le forum rapport de bugs. Une fois que quelqu'un a créé son topic, n'en créez pas de nouveau, postez dans le sien, en résumant au début de votre post les autres imperfections trouvées, mais pas corrigée.

Ainsi, si vous voyez une faute, une idée mal exprimée, etc, je pourrai tout corriger en une seule fois .

Les Llibs sont disponibles dans le SVN

Cliquez maintenant sur le lien "version SVN" : vous tombez sur la racine du SVN de Logram. Le dossier du dessus contient les sources des Llibs, celui d'en dessous celles du noyau Logram.

Compiler et tester les Llibs

Bonne nouvelle, vous n'avez, et n'aurez, pas besoin de construire un LFS pour tester les Llibs. Je les teste moi-même sous Ubuntu, et ça marche très bien.

Pour compiler les Llibs, placez-vous dans le dossier des sources, et faite "make" suivi de "sudo make install". Les Llibs se trouvent alors dans /usr/lib/. LibLDraw n'existe pas encore, le makefile échoue donc. Copiez manuellement le contenu du dossier include dans le dossier /usr/include/llibs/. Vous avez un environnement complet .

Pour tester les Llibs, un simple "make check" suffit. Vous pouvez aller jetter un oeil dans le dossier tests, pour voir comment on utilise les Llibs, c'est très simple. Pour créer votre propre application, n'importe où (donc pas dans les sources des Llibs), il vous suffit de la lier avec l'option -llcore (pour LCore), et d'inclure les fichier llibs/conf.h (pour tester la gestion des fichiers de configuration).

Pour pouvoir compiler et utiliser les Llibs, vous avez besoin, pour Ubuntu, de libc6-dev, ou de glibc-dev. En fait, vous devez simplement avoir les fichiers d'en-tête de la LibC.


Bonne question .

En fait, les Llibs feront plus qu'utiliser le framebuffer, et c'est d'ailleur pour ça que je commence par coder la gestion des fichiers de configuration : les Llibs géreront des pilotes graphiques, dont le fameux pilote de framebuffer, mais aussi le pilote ... SDL .

Ainsi, les applications Logram pourront être testées dans une fenêtre SDL d'une certaine résolution. Le problème, c'est que chaque application aura sa propre fenêtre SDL, bien qu'elles se partageront le framebuffer. Pas de soucis donc .

Le mot de la fin

Pour le moment, il n'y a que moi qui ai l'accès au Llibs (pour committer, vous pouvez les lire ). Dès que les bases seront jettées (donc justement la gestion des fenêtres, des images, le pilote SDL, et d'autres détails), le codage à plusieurs pourra commencer .

A plus.

Bonjour,

Il y a quelques mois, je vous avais fait une news qui rassemblait toute l'histoire du site. C'était intéressant, mais moins que ce qui va suivre : l'Histoire de Logram, quand il était caché chez moi, depuis plus de 6 ans et demi !

C'est un peu du racontage de vie, mais ça pourrait toujours vous intéresser de savoir pourquoi je dis de temps en temps "On fera ça comme ça et pas autrement", d'où je tire mes réflexions, et surtout ce qui fait que Logram est unique .

2002 : Progrâame

Quand je dis 6 ans, c'est vraiment 6 ans. C'est en fait facile à dater : j'ai acheté Visual Studio 2003, qui venait de sortir, et Visual Studio sort toujours un an avant la date marquée dessus !

A ce moment, Logram n'est qu'un embryon : j'ai vâgement une idée d'à quoi ressemblera l'interface graphique, encore très ressemblante à Windows. Je l'ai même entièrement codée en Visual Basic, ce qui m'a pris des mois, mais m'a permis de découvrir la programmation. Je n'ai malheureusement pas de screenshots, mais vous savez l'imaginer : un arrière-plan, une barre des tâches, avec le logo Logram dessus, et quelques utilitaires (pas mal en fait : un programme de dessin comme Paint, un visionneur de diaporamas, un panneau de configuration, un gestionnaire de base de donnée en XML, un programme de montage vidéo, un éditeur de texte (Texte-Up ), et d'autres petites chose).

Ce "Logram" (qui s'appelait encore Progrâame, j'étais spécial) nécessitait le .NET Framework 1.1.4322, un comble pour un OS !

2003 : Progrâame 2

Fini le .NET, je me documente, et me décide enfin à coder un vrai OS, en C, et un peu d'assembleur. Tout ce que je sais maintenant, je le tiens de cette période. Je signale aussi que je n'avais pas Internet, c'est pour ça que vous ne trouverez aucune trace de moi avant Février 2008, date à laquelle j'ai enfin eu Internet.

Maintenant, place au screenshots, ou plutôt aux vues d'artistes. Vous remarquerez que c'est devenu très différent de Windows :

Vous remarquerez que je n'était pas un excellent graphiste, et surtout que Logram n'avait pas encore de logo (oui, c'est bien Logram marqué dessus, et pas Progrâame. J'ai changé de nom parce que Progrâame ne rentrait pas sur le bouton ).

2004 : Logram grandi

Pas beaucoup de codage cette année, j'en avais marre ! Par contre, pas mal d'idée, de design, d'images, de mise en place. Autant j'ai tout appris en 2003, toute l'architecture de Logram a été entièrement pensée en 2004. Les rares fois où j'ai accès à Internet, je reste scotché à Wikipédia : je veux savoir comment marche un disque dur.

Nous avons quelques petites améliorations du côté du graphisme : Logram se trouve un logo, certes moche, mais logo quand-même :

Ici, quelques remarques, en particulier pour la ligne en dessous : je parle mal anglais, et je suis encore toujours tordu dans le choix de mes noms !

Vous ne voyez rien ? Et oui ! Evêr Fvision est l'ancien nom de Tébéas ! Quand je vous dis que tout a été pensé cette année !

Du côté de l'interface, nous avons ceci :

Ah, là maintenant, Logram devient unique. Vous remarquerez que je suis seul à connaître l'existance de Logram, ce qui fait qu'il n'évolue pas très vite, et surtout que mes idées (bonnes ou mauvaises) restent très longtemps en place (vous pensez quoi des couleurs ?).

2005 : Codage en assembleur

Alors maintenant, ça se complique fortement. Mon Logram en C ayant été un échec (j'avais fait tout le code, mais vraiment tout (fichiers, applications, threads, synchronisation, timers, file de messages, gestion des exceptions). Je compile ... ça marche pas . J'avais codé dans un C tellement .. douteux, avec plein d'inline assembly, sans pointeurs, sans structures, etc, que le compilateur m'a signalé plus de 2300 erreurs !

Une fois toutes les erreurs éliminées, il ne bootait pas : tous mes for() étaient faux.

Bref, je commence le Logram en assembleur, et c'est difficile. Entre deux codages, j'ai le temps de bâtir un empire, malheureusement détruit maintenant, à cause d'un plantage de Windows, et pas de sauvegardes. J'avais codé un jeu de passerelle (avec éditeur de niveau, etc), un casse brique, trois ou quatres sites webs, qui sont restés en local (et fait avec FrontPage ), etc. Logram évolue encore, toujours dans le même type d'idées (et de couleurs ) :

Il y a du changement. Pour l'anecdote, c'est à ce moment que je trouve moi-même (pas encore Internet) la formule de transparence : couleur = ((Pp-Ap)*Op)+Ap, où Pp est la couleur de premier plan, Ap celle d'arrière-plan, et Op l'opacité (0.3, 0.223, etc).

Bonne nouvelle : Logram en assembleur boot ! Mauvaise nouvelle : je ne connais pas encore Qemu, je l'installe sur un DD, et je dois rebooter mon ordi à chaque modification, et même deux fois : Windows >> Dos pour l'installation >> Logram pour tester >> Windows pour modifier. Logram affiche un magnifique écran jaune clair au démarrage. J'ai codé un petit chargeur d'images, voici :

L'année 2006 est la même que 2005, je fais toujours la même chose.

2007 : Linux

Logram en assemleur ayant été abandonné (mauvais à la base, et j'ai de nouveau fait l'erreur de tout coder avant de tester), je décide de le refaire en C. Pour cela, il me faut un compilateur qui sort du binaire, chose inexistante sous Windows.

Je dois donc passer à Linux, et je peux dire que ça n'a pas été facile : j'ai le malheur de tester Mandriva One 2007 Spring. C'est le genre de distrib qui met 6 minutes à booter, pour rien. J'avais juste FireFox en fait, et je devais démarre en console pour rebooter X, car ma carte graphique était mal détectée. De plus, aucune trace de GCC dessus ! N'ayant pas internet, je n'ai pas pu installer le paquet. J'ai donc fait une vaingtaine d'allé-retours au Cyber Café pour aller télécharger les sources, et je me suis frotté aux ... dépendances en boucles : comment compiler GCC sans avoir GCC ?

Pas de panique, je télécharge un GCC tout compilé, qui me réclame GAS ! Pas de GAS compilé malheureusement. Je télécharge les binutils, mais je ne peux pas les compiler . Je retourne sous Windows .

A la fin de l'année, j'essaye Ubuntu 7.10. Je dois à nouveau m'y reprendre plusieurs fois avant d'être séduit, car autant Windows est utilisable sans Internet (il y a des CD), autant Linux n'est rien sans le web. Je retourne sous Windows .

2008 : l'envol

Début 2008, j'obtiens internet, mais seulement les week-ends, et en wifi, ce qui est déjà pas mal du tout. Je me met confortablement à Linux, et je découvre l'univers du web : wikipédia, les recherches Google et ... le Site du Zéro !

Je suis tombé dessus au hasard d'une recherche sur la programmation de sites web, et j'ai bien aimé. Je suis encore retombé dessus en cherchant un truc sur le C, et je me souviendrai toujours de ce que je me suis dit : «M@téo21 a fait deux tutos sur deux sujets différents, il doit se faire aimer sur le site». J'avais raison .

Pour Logram, je code DeSte IDE : un IDE qui utilise le langage de programmation DeSte. Je le met comme source sur Codes Sources, et je recois un 10 . Je trouve ça chouette, c'est mon premier contact avec le "libre" (parce que Codes Sources est tout de même sponsorisé par MS, c'est la seule raison que j'ai trouvé pour qu'ils utilisent ASP .NET ). Je décide de partager Logram, et si vous faites une recherche, vous pouvez encore tomber sur la présentation de Logram, qui date un peu (version 0.0.0.3, c'est vous dire !).

Là, c'est de l'histoire connue pour les anciens membres : je recrute, beaucoup de monde arrive, on crée 4 versions différentes du site, etc.

Voilà, j'ai bien raconté ma vie, mais ça peut vous intéresser. J'ai fait ça car je suis tombé sur une vieille sauvegarde de mes documents. Je me suis dit «Pourquoi pas leur montrer tout ça ?».

A plus.

Bonjour,

Vu l'effervescence provoquée par la dernière news, vous devez être au courant des dernières informations. Je rappelle brièvement les faits :

Ca fait des années que je code Logram, et presque 6 mois (déjà ) que je le code avec le reste de l'équipe. Tout se passait très bien, et tout se passe encore très bien. Le problème, c'est que dans l'équipe, il y avait (royalbru est parti ) deux codeurs systèmes : moi et royalbru. Les autres suivaient le projet de près ou de loin, mais sans vraiment participer.

J'ai donc pris les choses en main : on va utiliser le noyau Linux (donc un noyau tout fait et qui a fait ses preuves) comme coeur de Logram. Le problème, c'est que le noyau Linux ne vient pas tout seul, il faut aussi lui ajouter quelques outils, comme Bash, GCC, les binutils, uDev, SysVinit, etc pour qu'il soit bootable. Cet ensemble d'utilitaire s'appelle le un LFS (pour Linux From Scratch). C'est très instructif, il vous apprend dès le départ à créer votre propre système, mais là n'est pas la question .

Un LFS n'est pas suffisant pour avoir un système correct, et surtout graphique. Je me suis donc posé la question, et j'ai posé cette même question au reste de l'équipe, de savoir à quel point il fallait intégrer des outils GNU dans ce LFS pour avoir Logram. Je m'exprime plus clairement : un LFS, c'est le shell Bash, et rien d'autre. Vous ne pouvez rien faire, ni même pinger votre routeur, ou aller sur internet. La seule chose qu'il permet, c'est de compiler d'autres applications.

L'architecture de Logram

Trêve de bavardages, passons aux choses sérieuses !

Le choix qui a plus ou moins été retenu (pas beaucoup de personnes se sont prononcées) a été de prendre le noyau Linux, ainsi que quelques outils GNU (GCC, mais aussi les net-tools, Lynx, et d'autres petites applications sympa), et de tout construire autour. Il restait un choix à faire : X11 ou pas X11, pour le mode graphique.

J'ai donc installé X11 sur mon LFS, et j'ai vu que c'est très lourd pour pas grand chose (bon, on a quand-même la gestion des polices, la gestion des événements, etc), mais ça reste limité à du "connu".

Voici donc ce que je propose : utiliser le framebuffer. Rien de plus simple, rien de plus rapide, rien de plus amusant instructif. Ca va plaire aux développeurs avancés, et surtout, ça va permettre de faire ce qu'on veut (onglets, IA, compatibilité Windows (bon, ça c'est pas graphique), etc) !

Le principe est simple (attention, ce qui suit est relativement technique) : le framebuffer est un fichier (/dev/fb0 en l'occurance) dans lequel on écrit. La différence entre ce fichier et un autre, c'est que tout ce qu'on écrit dedans est affiché à l'écran . Par exemple, pour afficher un pixel vert à la position 10x10, on place la valeur 0x0000FF00 dans le dword situé à (10*largeur_écran)+10. On a un pixel vert de dessiné.

Bien évidemment, les applications ne vont pas s'amuser à écrire dans ce fichier, loin de là. Elles vont utiliser la signature de Logram, son cachet si vous préférez, ce qui va le rendre unique : les Logram's libs.

Les Logram's Libs seront un ensemble de bibliothèques que pourront utiliser les applications, un peu comme une API : elle feront tout, absolument tout. Le but des Llibs, c'est de proposer aux applications un environnement normalisé, et puissant, un peu comme Qt. Le gros avantage, c'est comme KDE et ses kdelibs, c'est qu'on charge au démarrage les Llibs, et qu'on n'y touche plus. Les applications démarreront donc à la vitesse de l'éclair !

Les Llibs, en plus de gérer l'aspect graphique, géreront aussi tout le système. A nouveau, je me base sur KDE qui m'a beaucoup impressionné de ce côté : toutes les applications KDE peuvent utiliser les Kio-Slaves, et d'autres mécanismes vraiment puissants. Les Llibs permetteront également ceci, par exemple, une application pourra très facilement accéder à un fichier sur un FTP avec cette simple ligne de commande :

Code : cpp
Les Llibs se chargeront d'afficher si nécessaire une boîte de login, de gérer la connexion, et de retourner le résultat.


Pas tellement. Les Llibs seront une interface, et contiendront toute la logique, mais elles relègeront à d'autres librairies le sâle boulot (libftp, libxml, libpng, etc). Ainsi, les Llibs seront puissantes, sans trop de travail, et donc sans trop de bugs !

Autour des Llibs, l'environnement de bureau Logram, et tout ce qui va avec. Avec ça, on aura, sur un système Logram de base, 80% de code Logram, et 20% de code GNU (sachant que par exemple, pour le noyau Linux, ce ne sont que des pilotes).

Participer au codage de Logram

Vous voulez participer au codage de Logram, c'est simple, ça se fait en étapes :

• Il vous faut une base. Le LFS (adresse plus haut) est une très bonne base, et pas trop difficile à mettre en place (j'avertis juste d'une chose : Logram basé sur Linux sera portable. Il faut donc savoir le construire. Le LFS en 32-bit marche impec. en 64-bit, il faut quelques manipulations : construire les binutils dans leur dossier (pas dans un autre, il y a un fichier qui manque), ajouter à ./configure de GCC --diable-multilib, et copier/coller GRUB de votre distrib vers le LFS. Il faut également, au tout début, créer les dossier /lib et /usr/lib, et créer un lien symbolique de /lib64 et /usr/lib64 vers ces dossiers. Le but est de faire en sorte que /lib=/lib64 et que /usr/lib=/usr/lib64).
• Une fois le LFS fait, il faut le configurer. Je vous conseille fortmenent d'être connecté en Ethernet, quoique le wifi, avec les bons pilotes, marche aussi. Là, il faut aussi quelques conseils : pas de dhcp (il plante), et surtout, une fois que tout est bien configurer, ajouter la route par défaut : "route add default gw 192.168.0.1 netmask 255.255.255.0". Sans ça, impossible de sortir du réseau.
• Se connecter au dépôt SVN de Logram, et télécharger les fichiers sources.

Je crois avoir tout dit, bon dév. .

L'organisation de Logram

Logram s'organise aussi. Soyons clair, ce chapitre sera moins fourni que le précédant, car qui dit organisation, dit discussion, et ça prend déjà plus de temps. Voici donc simplement les bases de l'organisation de Logram.

Au lieu d'être linéaire (tout le monde donne des ordres à tout le monde, et en recoit), ce qui menait à rien, on va organiser tout ça hiérarchiquement.

En haut de la pyramise, les chefs de projets (moi et un autre, si jamais le wifi me joue des tours je suis indisponible pour un moment, ou très occupé, comme maintenant avec le LFS). Ils seront au courant de tout, les informations leur seront présentée correctement et clairement par les autres membres. Ainsi, ils auront une vue générale de Logram, et pourront donc gérer le projet en entier, sans l'éclater, et en pouvant toujours synchroniser les différentes tâches, et tout coordonner.

À l'étage du millieu, nous trouverons les directeurs de projet (si vous avez un meilleur nom, dites-le moi ). Ils seront au nombre de 3-4 ou un peu plus, et seront les directeurs de sous équipes. Leur boulot : coordonner les membres de leur équipe, et informer les chefs de projet de ce qui se passe (de manière synthétisée, etc).

En "bas" (mais en réalité, ce seront les personnes les plus importantes) se trouveront les éxécuteurs. Ils feront le travail. Rassurez-vous, ce ne sera pas une tyranie. Les directeurs de projets pourront être également éxécuteurs, etc. C'est comme maintenant : un modo est un membre, et un modo peut locker le topic d'un autre modo (voir le ban ).

Bref, tout ceci commence à prendre forme, mais c'est encore un petit peu flou.

Conclusion

Je crois que c'est tout. Je précise que vous pouvez à nouveau poster des commentaires de news, j'ai désactivé l'envoi automatique de MPs (je me demande comment ça se fait qu'un truc pareil a été codé ).

Je précise que rien n'est fait, ce n'est qu'une synthèse du topic "Discussion IRC" (dans On se détend), qui résume quelques idées données, et mes propres réflexions. Si vous voulez vous opposer à quelque chose, ou en débattre, ou poser des questions, ne vous privez pas (mais s'il vous plaît, évitez de parler sans vous renseigner, comme pour la news précédante : «C'est pas nous qui le faisons ça puxx»).

Bon débat .

Bonjour,

Avant tout, je vous signale que nous allons parler de choses très sérieuses, ce n'est pas un poisson d'avril (nous sommes loin du 1er d'avril).


Pas de panique, tout va bien, je ne fais que vous annoncer de "bonnes" nouvelles.

Qu'est-ce que Logram, qu'est-ce qu'il doit être

Entrons dans le vif du sujet : Logram stagne (désolé de le dire comme ça). Ce n'est pas une question de manque de développement, mais plutôt d'avoir trop de choses à faire. Je ne suis pas défaitistes, justement, j'évite un mur.

Quatre solutions s'offrent à nous pour créer un OS performant, libre, etc :

• Le coder de A à Z, et 5-6 ans plus tard, obtenir un truc qui marche plus ou moins, peu performant, et plein de failles
• Utiliser quelque chose de tout fait : le noyau Linux, et construire autour (GNU/Linux => Logram/Linux)
• Créer une distrib, avec les outils GNU : GNU/Linux Logram
• Créer un environnement de bureau avec gestion des onglets

Il va de soi que si on prend une puce, il faut aussi réaliser les suivantes. Par exemple, si on décide de faire Logram/Linux, une fois les outils faits, il faudra créer la distrib autour.

Bref, pour obtenir ce qu'on veut, on ne peut pas réinventer la roue sans se planter.

L'honneur ou la raison

Je sais ce que vous pensez : il y a déjà beaucoup de distros, et le noyau Linux est déjà fini. Pesons le pour et le contre :

Contre

• On n'aura pas la satisfaction d'avoir absolument tout fait
• On ne maîtrisera pas à 100% les outils mis en place

Pour

• On ne se plantera pas, car le noyau Linux marche, les outils GNU aussi, on va construire sur des bases sûres, et accessoirement, c'est du travail en moins
• C'est plus developper-friendly, au lieu d'être moi, royalbru, tr1691 et quelques rares autres, on va pouvoir être des centaines à coder, car utiliser une bibliothèque graphique est vraiment plus agréable que d'avoir à la coder .
• Ce sera plus performant, on aura d'office la maturité de Linux, la puissance des outils GNU (Bash & co, les binutils, GCC, des libs, etc)
• Le lancement sera plus simple : au lieu de devoir tout recoder, les applis marcheront directement. De plus, au lieu de présenter dans la PdZ un truc qui boot plus ou moins, on présentera un environnement prometteur et utilisable.
• Il y a moyen de se différencier : ce n'est pas parce qu'on fait notre propre distrib qu'on se fond dans la masse, si on la fait bien (nos propres outils, notre propre environnement de bureau, etc), il y a moyen qu'en apparence, Linux Logram soit comme Logram tout court, de même pour les fonctionnalités

Bref, malgré les apparences, il y a de fameux avantages par rapport aux quelques inconvénients.

À coder, à pas coder, ...

Maintenant se pose la question : on code quoi ?

De toutes façons, on ne va pas recoder le noyau Linux, et tout ce qu'il implique (pilotes, système de fichier, architecture, etc). Maintenant, voici la liste de ce qu'on pourrait recoder :

• Les outils GNU de base (démarrage, Bash, etc). Je n'ai pas vraiment envie de refaire ça
• Les outils GNU&co de surface : gestionnaire de fenêtre, décorateur, serveur x11, etc : c'est malheureusement à refaire si on veut bien faire, mais vraiment très difficilement (et puis, ça marche quand-même)
• Les outils visible : environnement de bureau, assistants, bref, transformer Linux en un OS attraillant pour les utilisateurs, et le faire connaître (j'aime bien ce point de vue )
• Une bête distrib : assembler des outils+GNOME+APT et faire un Ubuntu-like, mais avec nos outils de conf, je n'aime pas du tout.

Il apparaît que le plus intéressant à faire serait de créer les outils de surface : l'environnement de bureau (c'est assez suicidaire pour que ça vous plaise ), les assistants de configuration, etc, pour obtenir un système unique et qui marche.

Si on fait plus (recoder les outils), c'est dangereux, car on n'arrivera que très difficilement à la perfection des outils actuels, et en beaucoup trop de temps : plus un projet dure avant d'être utilisable, au plus il a des chances de sombrer dans l'oubli.

Si on fait moins (juste une distrib), on n'aura pour ainsi dire rien fait, à part DL des sources, les compiler, éditer des fichiers de conf, et créer un .deb (j'aime vraiment bien APT ).

Conslusion

Je vous laisse choisisr, je sais que le débat sera annimé, qu'il y a peux de chances qu'on soit tout de suite d'accord, mais il faut se rendre à l'évidence, en 6 ans, Logram ne boot même pas encore tout à fait. Ce n'est pas sa mort, loin de là : c'est comme opérer d'une tumeur au cerveau. Soit on vie difficilement avec des facultés mentales réduites (bugs au niveau informatique) soit on opère, on aura plus le mérite de «survivre à la tumeur», mais on vivera pleinement et plus longtemps.

Bonne discussion .