HappyPeng a écrit 324 commentaires

CSS est un moyen de rendre un document XML, y compris sur papier (il existe un media "paper" pour les CSS), il est donc logique de disposer d'un logiciel qui, à partir d'un document XML et d'une feuille XSL produise un document PDF ou autre format adapté à l'impression, par exemple.

Je ne comprends pas toutes ces réactions critiques étant donné qu'il n'existe pas d'autre solution libre pour cette technologie, à part ouvrir dans Mozilla et cliquer sur "Imprimer".

Il faut savoir qu'il y a une grosse architecture d'objets et de composants sous Mozilla en général et donc sous Gecko. Ils ont fait un effort de réutilisabilité du code, etc. Simplement, la pratique semble ne pas suivre ...

Au contraire, je pense qu'il est utile d'avoir un moteur de rendu de documents XML avec des CSS, notamment pour des applications non-XHTML, par exemple lorsqu'il s'agit de rendre du DocBook en PDF, ou autres choses concernant la documentation (technique).

Au jour d'aujourd'hui en ce qui concerne le libre je ne vois aucune autre solution qui permette de faire cela.

Peut-être parce que Steve Jobs juge que ça serait tellement risqué d'entrer en confrontation directe avec Microsoft que c'en serait stupide.

Pour mes utilisateurs lambda, a l'issue de la copie d'un CD tu as un autre CD, m'enfin bon ...

Donc on tient vraiment à les faire passer du rang d'exploités à celui d'exploiteurs ? Vivement une troisième voie.

Je suis d'accord, mais également je ne pense pas que "en voie de développement" soit une expression très positive.

J'ai surtout l'impression que les pays dits "développés" pseudo-aident les dits "en voie de développement" d'abord dans le but de pouvoir les exploiter (on a des fabricants de chaussures pas chers, puis des ouvriers pas chers, des techniciens pas chers, maintenant des codeurs pas chers) et ensuite sous réserve qu'ils suivent le modèle imposé par le "libéralisme à l'Américaine" (je sais pas vraiment comment on dit).

Mieux vaudrait qu'ils soient en voie de progrès humain qu'en voie de développement économique.

My two cents, je dis encore des trucs sans intérêts.

A propos de RPL/2, j'aime assez cet outil. Dommage vraiment que le code soit en Français !

Le Common Lisp permet aux fonctions (et aux méthodes) de renvoyer plusieurs valeurs.

Par exemple :
* (defun x () (values 1 2 3 4))

X
* (x)

1
2
3
4
* (multiple-value-bind (a b c d) (x) (+ a b c d))

10

Ici x renvoie quatre valeurs.

Tout cela est très bien, mais comment utiliser ça dans une application classique ?

Il me semble qu'il est déjà possible de faire smb:// dans Mozilla grâce à GNOME-VFS.

Ca n'a rien à faire dans la choucroute, mais pour ne pas niveller par le bas, SWT implémente lui-même les fonctionnalités dont il a besoin lorsqu'elles ne sont pas présentes dans le toolkit qu'il utilise (comme le MDI).

Le problème n'est pas que celui de l'aspect puisqu'en choisissant entre GTK+ et Qt il faut également choisir entre différents designs, différents styles de code, différentes fonctionnalités et implémentations des idées ... En bref, une Grande Unification (tout le monde utilise le même toolkit) me paraît assez improbable tant que les gens auront (et j'espère que ce sera toujours le cas !) des idées différentes sur "comment bien écrire un logiciel" (et le tout en se faisant plaisir, dans le cas de bénévoles :-)

Je suis tout-à-fait d'accord avec cette position (mais pas forcément tout-à-fait avec l'UML et le C++ :-) qui consiste en le développement de composants réutilisables orientés vers l'édition XML.

Notre bien aimé et excellent maintainer, Dodji Seketeli, à d'ailleurs écrit, dans le but de l'utiliser pour MlView, une bibliothèque "boîte à outils" pour les CSS (libcroco) ainsi qu'un moteur de rendu XML basé sur les CSS (sewfox). Ces deux outils sont parfaitement réutilisables pour d'autres applications, ainsi libcroco est actuellement utilisée par librsvg et des développeurs de KSVG.

La base de MlView est libxml2 (de Daniel Veillard), qui est à mon avis -le- meilleur toolkit XML disponible et propose énormément de fonctionnalités ; libxml2 est également utilisable et utilisé par de nombreuses applications, qu'elles soient GNOME, KDE ou bien aucun des deux.

A partir de là, nous avons également pensé sortir de MlView (pour les mettre dans des bibliothèques réutilisables) certaines pièces comme le modèle de document (DOM) qui pourraient alors être développées et utilisées en commun par d'autres éditeurs (GNOME ou non).

En ce qui concerne kxmleditor, il utilise le module XML de Qt, qui est loin d'être aussi puissant et performant que libxml2 et qu'il est impossible d'utiliser dans une application GNOME. Par conséquent, il serait fort difficile de partager des composants avec cet éditeur.

Une connerie a mon avis, vu que sur un 'char *' tu as plus de doute sur la nature de l'encodage utilise justement.

Sauf que GString est un outil (basiquement une struct avec un gchar* et deux tailles) qui ne tient absolument pas compte de l'encoding et possède donc les mêmes inconvénients sur cet aspect qu'un char*.

Je pense qu'en effet il aurait été souhaitable de se mettre d'accord sur un encoding, car faute de pouvoir en supporter systématiquement plusieurs et d'aussi différents, ça posera des problèmes lorsqu'il s'agira d'utiliser d'autres bibliothèques libres.

Ou sous GNOME, mlview, qui a des fonctionnalités que kxmleditor n'a pas (la validation par exemple).

C'est quoi le rapport avec la choucroute ? (À part justifier le fait que Qt soit en C++ ...)

C'est exactement ce que j'ai dit : si l'objet est d'une classe qui possède au moins une méthode virtual, les erreurs de typage apparaîtront à l'exécution et non à la compilation comme c'est le cas avec les autres objets.

Le problème pour moi n'est pas l'apparition d'erreurs à l'exécution (ce peut être également le cas avec des langages comme l'Objective-C) mais l'incohérence du double système. La solution proposée par Ocaml paraît également plus cohérente (et radicalement opposée).

La possibilité de faire du non-virtual semble avant tout être dictée par le choix de la performance et de la rigidité du purement statique. Cependant je suis d'accord sur le fait que le comportement différent entre virtual et non-virtual (et entre objets contenant au moins une méthode virtual et n'en contenant aucune) est déroutant voir illogique et peut être source d'erreurs (on ne sait pas toujours si les erreurs vont apparaître à la compilation ou à l'exécution, par exemple).

Sans oublier Objective-C, bien entendu.

Pourquoi ? Le terme communauté est breveté ? Seul le libre peut utiliser communauté ?

Il me paraissait assez clair qu'il n'y avait pas lieu de tergiverser si le mot communauté désignait ceux qui avaient de toute façon déjà opté pour Java. J'ai donc pensé qu'il parlait de la communauté du logiciel libre en général.

Et la confiance renouvellée de Apache avec le passage du projet Geronimo comme projet de premier niveau prouve que le temps n'est plus aux tergiversations dans la communauté.

Vous utilisez abusivement le mot communauté pour désigner des développeurs et des utilisateurs qui ont pour l'instant fait le choix de fonder leur travail sur une solution quasi exclusivement propriétaire, avec la machine virtuelle (les environnements J2EE libres et les projets Apache en Java ne tournent pas ou peu sur des machines virtuelles libres, etc.). Mais ce n'est pas le choix de tous (en particulier ça n'est pas le mien) et même d'entreprises importantes pour le libre telles RedHat (qui a choisi de libérer Eclipse de la machine virtuelle de Sun en adaptant la machine virtuelle de GNU, gcj/gij, et Eclipse pour qu'ils puissent fonctionner ensemble).

L'heure est donc bel et bien aux tergiversations, lorsqu'il s'agit de sujets aussi primordiaux. Comment tournerait un programme écrit en C sans compilateur ? Alors comment tournerait un programme écrit en Java ou en C# sans les environnements correspondants ? Tant qu'il subsistera un doute sur la viabilité de ces environnements pour le logiciel libre au point de vue licence, il y aura bien tergiversation.

Pour ceux qui parlent des spécifications Sun : est-il de toute façon possible qu'une implémentation libre puisse suivre au même rythme que sort le code nécessitant la toute dernière version (Looking Glass demande comme par hasard une bêta de Java 1.5) ?

Je pense que la moindre des choses quand on réalise un site Web sur les bonnes pratiques, dont certaines parlent du validateur du W3C, est de passer son propre site au validateur, et de réaliser un sans faute :-)

Bon, ils spécifient une DTD (qualité 1 selon eux), ils spécifient l'encoding (qualité 1 selon eux) et ils font moins de 25 erreurs (qualité 2 selon eux), puisque le validateur officiel n'en trouve qu'une sur la page d'accueil, mais je trouve quand même cela assez comique.

Pour l'instant, il n'existe pas de wrappers Objective-C pour GTK+ 2.x qui soient releasées, même si je suis moi même en train d'en coder (la base est déjà prête, j'ai d'ailleurs codé pour la démonstration un navigateur Web minimaliste utilisant l'intégration GTK+/Gecko, dont vous pouvez voir un screenshot : http://happypeng.free.fr/screenshots/wb.png(...) et le code source extrêmement minimaliste, utilisant libglade : http://happypeng.free.fr/wb/wb.m(...)). Une archive GNU arch (assez obsolète, je vais en créer une autre) du code source complet est disponible ici : http://happypeng.free.fr/objgtk/(...) .

Mais ceci dit, sur la lignée des wrappers Objective-C pour GTK+ 1.x et GNOME 1.x, il n'existe aucun lien avec GNUstep et le choix a été fait d'un environnement complètement intégré à GNOME et sans dépendances envers GNUstep, dont je n'apprécie pas d'ailleurs forcément les API par rapport à la simplicité extrême de ceux de GNOME (et je ne parle pas de l'utilisation du C, puisque c'est justement cela qui permet à GNOME d'avoir d'excellents wrappers C++, C#, Java, plein de langages interprétés et éventuellement Objective-C, donc il y en a pour tous les goûts : personne ne vous oblige à coder en C parce que vous codez en utilisant GTK+).

GNUstep ne pourrait de toute façon pas utiliser GTK+ puisqu'il dessine lui-même ses widgets. Par contre, une option qui a été choisie pour des wrappers GTK+ 1.x "concurrents" de ceux développés par des membres du projet GNOME est de faire un GTKKit, c'est-à-dire une bibliothèque parfaitement intégrée à GNUstep mais représentant un jeu de widgets concurrent de celui proposé par défaut par GNUstep.

Pour ceux que ça intéresse, trouvez moi sur IRC.

Ou en encore plus beau :

http://happypeng.free.fr/screenshots/file-manager.png(...)