rewind a écrit 3425 commentaires

Il n'y a actuellement aucun problème de rendu avec les jointures. Je te conseille de lancer par exemple la démo Qt4 pathstroke (package qt4-demos dans Debian) pour te rendre compte des possibilités. Tout est déjà implémenté et de bien belle manière, donc inutile de refaire ce travail à mon sens.

Non, ce n'est pas exactement la même chose. Parce que dans un trait, il y a deux éléments qui sont pris en compte dans le modèle de dessin actuel : la manière dont la jointure entre deux traits consécutifs dans un chemin est dessinée et la manière dont le bout du trait est dessiné. Sans compter le fait qu'on puisse faire des pointillés facilement. Si on considère qu'un trait est un rectangle, on doit réimplémenter ces éléments d'une manière ou d'une autre. Et je n'aborde même pas le cas des traits courbes.

Encore heureux. #ifdef c'est sale. Un programme bien conçu n'utilise pas #ifdef pour assurer la portabilité, mais il sépare le code portable et le code dépendant d'une plateforme dans des fichiers différents, et laisse le système de build choisir quels fichiers compiler.

Tu devrais en parler à Lennart, il n'est pas au courant.

Tu es en train de me dire qu'un utilisateur qui n'a pas les capacités de contribuer n'a d'autre choix que de fermer sa gueule.

Non, ça c'est toi qui le dit. Moi, j'ai posé la question.

Des devs bénévoles

C'est tout à fait ça, Lennart c'est un brave bénévole, il vit d'amour et d'eau fraîche.

Susceptible, hein ?
Remarque pourtant que je n’ai pas dit « ça ne sert à rien » ou « ça existe déjà ». J’ai demandé « pourquoi ? ».

J'attendais mieux d'un premier commentaire que trois lignes qu'on retrouve systématiquement, quel que soit la proposition qui est faite.

La problématique d’un langage descriptif de dessin vectoriel a déjà été traitée plusieurs fois. Et les questions que tu exposes ont aussi été traitées par ces formats.

Et les réponses apportées diffèrent parfois, donc ça montre que rien n'est figé.

Et ne méprends pas ce que je dis, comme tu l’as déjà si facilement fait avec ta gueulante.

Ben c'est tombé sur toi, mais ça ne t'étais pas destiné spécialement.

Je dis qu’il y a eu des réponses, que ces réponses peuvent avoir des défauts mais que jeter tout ce qui existe sans critique, c’est-à-dire sans étudier les forces et les faiblesses, est une attitude puérile et non constructive.

Qui te dit que je ne l'ai pas fait ? Simplement, je n'ai pas fait d'état de l'art dans ce journal parce que ça ne me semblait pas nécessaire. Mais je pourrais, il suffit de lire une partie de mes réponses et tu auras ta réponse.

Et, moi aussi, je peux pousser une gueulante, envers tout ceux qui, quand on leur pose une question pour qu’ils approfondissent leur questionnement, pensent immédiatement et sans aucun doute que l’on n’est rien que des méchants vilains qui veulent tuer leur merveilleuse idée dans l’œuf, empêcher toute forme d’innovation et dénier leur fabuleuse créativité.

Dans ces cas là, écris un peu plus de trois lignes et ta critique sera plus crédible.

Cette réponse serait pertinente si tout utilisateur avait les capacités pour contribuer, ce qui est très loin d'être le cas. Ensuite, il y a ceux qui ont les capacités mais qui font autre chose, qui contribuent autre part. Enfin, il y a ceux qui peuvent contribuer et qu'on envoie chier (genre «non, non, on ne mettra pas de #ifdef dans mon code pour assurer une meilleure portabilité»).

Pour moi, un utilisateur n'a aucun droit, et encore moins le droit de faire chier le monde en râlant sans cesse.

En gros, il a le droit de fermer sa gueule, c'est ça ?

Plus que le choix, c'est avant tout l'entremêlement de couches qui n'ont a priori rien à voir les unes avec les autres qui m'inquiètent. Quand on lit que GNOME pourra dépendre d'un init particulier, on croit rêver… Oser prononcer ce genre de phrases quelques années en arrière relevait de la folie pure.

Moi j'attends la première alerte de sécurité dans systemd pour refroidir un peu tout le monde.

On doit pouvoir afficher n'importe quoi à partir du PS, donc en créant un language qui exportera en PS, ça t'évitera l'étape fastidueuse de la gestion de l'affichage, sauf si le challenge de ce type de développement te motive, ce qui peut être également une bonne raison.

Heu, pour l'export, je vais tranquillement me reposer sur cairo (je pense) qui a un backend PS, un backend PDF, et aussi des backend pour les principaux systèmes d'affichage (Xlib et XCB pour Linux and co par exemple) ce qui permettra d'avoir une sorte de preview de l'image. De cette manière, je ne m'occupe que du «frontend» et je laisse le «backend» (ce qui correspond à la génération de code pour un compilateur) à cairo qui va me générer les bons formats.

Pour en revenir à graphviz, désolé d'insister, mais il est possible d'y intégrer des formes personnalisées.

Avec les liens que je vois, on est obligé de passer par un fichier externe. Ou alors, on est limité à la boîte rectangulaire. Du coup, on n'est pas très avancé. Je ne dénigre pas Graphviz hein, je le trouve merveilleux dans son domaine de prédilection et je l'utilise assez souvent pour ça. Je l'ai aussi utilisé pour faire des diagrammes de classes UML, ça marchait à merveille. Mais là, je ne vois pas bien comment être flexible avec Graphviz.

Pour moi, l'idéal (je sais pas si tu compte le faire) serait d'ajouter la possibilité de définir des animations de ces formes

En fait, ça fait partie des questions que je me pose : est-ce qu'un fichier correspond à une seule figure ou alors, est-ce qu'un fichier peut produire plusieurs figures ? Je vois des avantages et inconvénients dans les deux approches.

d'ajouter aussi des boites textes (si ce n'est pas déjà présent)

C'est prévu, mais je préfère prendre mon temps sur ce point parce que dès qu'on parle de texte, c'est très vite la galère (les caractères non latins, les fontes, toussa).

Voilà qui répond à une de mes questions : dans Diagrams, ils utilisent des formes relatives. Effectivement, la sémantique est intéressante et je vais regarder ça de plus près. J'avais dans l'idée d'arriver à ce genre d'opérateur (qu'on rencontre aussi dans TikZ). Reste à trouver une syntaxe simple pour l'exprimer.

Là tu me parles du fonctionnement interne du logiciel non ? Moi je m'en tenais à la manière la plus « logique » de l'écrire pour un être humain.

Ben justement, je ne sais pas ce qui est le plus «logique» pour un être humain : relatif ou absolu. Comme ça, je dirais qu'un être humain trouvera plus logique de placer de manière absolue. Mais je peux me tromper. Avoir les deux serait l'idéal, en effet. Je vais peut-être recycler mes formes en double de cette manière. Je ne sais pas encore.

Mais tu dois en avoir l'habitude, t'es souvent dans le coin.

Oui, je connais la maison. Et ça m'exaspère déjà quand ça arrive aux autres ;)

je pensais à un truc à propos de la méthode « Qt ». Elle peut permettre aussi de créer une forme sans la dessiner, puis plus tard de la réutiliser en utilisant au choix brush et/ou pen pour la dessiner.

Pour ça, il y a les variables… et POV-Ray qui fournit des super idées. Dans POV-Ray, on peut définir des variables qui contiennent des objets, donc ils ne sont pas dessinés. Ensuite, il y a un objet générique qui permet d'étendre un autre objet qu'on a mis dans une variable. Je compte bien m'en inspirer. Un petit exemple pour comprendre. On veut dessiner deux lignes quasi identiques, une rouge et l'autre un peu plus bas :

set L = line { <10., 10.> <20., 10.> }

object { L
  pigment { rgb <1., 0., 0.> }
}

object { L
  translate { <0., 10.>
}

On peut d'ailleurs faire pareil avec les modificateurs (propriétés ou transformations) et des modificateurs génériques.

Donc, oui, ça sera possible, et même assez rapidement.

Je connais peu Postscript et Metapost dans le détail, mais ce qu'ils font et comment ils le font ressemble à ce que tu veux développer de ton côté.

Tout à fait. Comme je l'ai dit dans le journal, les API de dessin actuelles sont toutes calqués sur le modèle PDF, lui-même hérité de PostScript. En fait la différence entre PostScript et PDF est que PostScript avait des structures de contrôles (if, for, etc) que PDF n'a pas. Donc quand on transforme un PS en PDF, on se contente d'interpréter le PS et on envoie toutes les commandes de base dans le PDF. La filiation est donc assez naturelle.

Maintenant, le modèle PS a aussi ses limites, ne serait-ce que par sa syntaxe très déroutante. Et étendre PS me semble compliqué.

je ne trouve pas cela beaucoup plus lisible que du SVG (enfin, si un peu quand même, mais pour se faire une représentation mentale du diagramme, autant le SVG que l'autre me semblent impossibles)

L'idée, c'est de pouvoir avoir par la suite, des bibliothèques d'objets prédéfinis et de ne manipuler que ces objets avec des opérateurs haut-niveau. Par exemple, imaginons qu'on veut dessiner un réseau de deux machines. On aura un objet computer qui dessine un petit ordinateur et on écrira quelque chose du genre :

set A = <10., 10.>
set B = <20., 20.>
line { A, B }
object {
  computer
  at A
}
object {
  computer
  at B
}

Pour en revenir à Graphviz, c'est utilisé pour réaliser des organigrammes (cf. le logo), pas juste des graph donc c'est en plein dans ce que tu cherches, sauf si tu n'as pas tout expliqué dans les raisons qui te motivent pour créer ce nouvel outil.

C'est vrai que je n'ai pas expliqué l'usage que je veux en avoir. J'ai souvent besoin d'avoir des diagrammes ou des figures pour illustrer mes cours ou mes articles (je suis enseignant-chercheur). J'ai essayé pas mal de choses. Pendant longtemps, j'ai utilisé Dia, ça me convenait assez bien même si ça m'énervait de ne pas, par exemple, pouvoir placer les formes de manière un peu carré naturellement, par exemple avec des espacements identiques entre objets (le seul moyen est de passer par la grille magnétique qui est vraiment de mon point de vue un outil de placement du pauvre). L'avantage de Dia, c'est qu'on peut générer le fichier final qui va bien directement en ligne de commande, mais en revanche, on ne peut pas générer du PDF depuis la ligne de commande, il faut passer par l'export depuis l'interface graphique. J'utilise aussi gnuplot et graphviz quand c'est approprié, et idem, j'aime pouvoir tout piloter depuis la ligne de commande, parce que quand on modifie un diagramme et qu'on a juste à faire make pour que ça retransforme et recompile tout, c'est quand même pratique.

Il y a le problème inverse avec Boost : on ne peut désactiver ni le RTTI, ni les exceptions parce que Boost les utilisent les deux.

C'est marrant, quand on t'écoute, on a l'impression que Qt et GTK pètent tous les quatre matins. Alors que pas du tout. Simplement, ils ont tous les deux cassé la compatibilité binaire récemment (Qt3 à Qt4 et GTK2 à GTK3) en mettant en place un programme de transition qui a duré plusieurs années. Et avant ça, ils ont conservé la compatibilité binaire en gros une dizaine d'année chacun.

Si on compare à Gecko qui pètait la compatibilité quasiment à toutes les versions, soit tous les 6 mois, tu as raison, c'est incomparable. Je n'ai jamais entendu de développeurs se plaindre de la compatibilité binaire de Qt ou GTK, en revanche j'en ai entendu beaucoup se plaindre de celle de Gecko.

Comme déjà dit plus haut, TikZ a une courbe d'apprentissage très rude. je l'ai déjà utilisé une fois, en une journée, j'ai à peine réussi à faire trois ronds et 4 traits, ça m'a déprimé. Mon but n'est pas de faire aussi bien ou mieux que TikZ, mais de faire différent, d'explorer éventuellement de nouvelles manière de faire les choses, et peut-être de s'inspirer de quelques fonctionnalités de TikZ (comme le positionnement relatif).

Tiens, je vais en profiter pour pousser un coup de gueule. Parce que je trouve un peu facile de ressortir cette image à chaque fois que quelqu'un propose une variation sur un thème.

Je n'ai pas l'intention de faire un nouveau standard qui surpassera tous les autres, j'ai l'intention de faire un truc qui me plaît, et que je pourrai utiliser parce que j'en ai le besoin et que je n'arrive pas à trouver chaussure à mon pied avec l'existant. C'est comme ça que l'informatique fonctionne depuis le début. Si on avait pas créé de nouveaux outils, on en serait encore à Cobol. Si on ne peut plus rien faire sous prétexte qu'il y a déjà quelque chose d'approchant, ça va vite devenir galère de coder.

Bref, j'ai posé des questions, j'aimerais avoir des réponses. Ceux qui considèrent que ce que je fais est inutile peuvent s'abstenir de commenter et aller sur les nombreux journaux à troll.

Pourquoi pas la possibilité de laisser le choix à l'utilisateur, c'est-à-dire de proposer les deux ? Ça pourrait être un gros plus, par exemple en donnant la possibilité de faire des formes « macro » en relatif, puis de les positionner et rajouter d'autres trucs en absolu. Quelque part c'est un peu comme ça que html/css fonctionne, et c'est pas mal.

Tout à fait. Mais n'avoir que des forme absolue n'empêche pas ce que tu dis. Une petite tranlation et hop. Il est assez facile de calculer la boîte englobante (bounding box) d'une forme, et donc de déplacer la forme où on souhaite, éventuellement en réajustant la taille. Juste en donnant le point d'arrivée, tout le reste peut être calculé automatiquement.

Merci pour ces retours constructifs.

Asymptote est pas mal. Je crois que je vais le regarder de plus près, ça peut donner des idées.

Pour ditaa et asciiflow, on ne peut pas dire que la réutilisabilité soit idéale. Si on veut composer des figures, c'est assez difficile.

Quant à Graphviz, il est orienté graphe. Je l'utilise pour ça, mais là, je veux un peu plus que des graphes.

SVG n'est pas fait pour être édité à la main. Et PGF/TikZ a une courbe d'apprentissage très rude.

Et on peut faire tourner des applis codés pour Gecko 1.7 avec Gecko 14.0 ?

Pour le coup, la marque en question est présente dans une bonne partie du monde (Amérique du Sud, Asie, Europe du sud) mais pas au Québec.

Rien, puisque la Guerre des boutons a rejoint le domaine public en octobre 2010 (c'est d'ailleurs la raison qui a fait qu'on a vu deux films sur le même sujet). Même chose d'ailleurs pour la colorisation du Voyage dans la lune qui a rejoint le domaine public récemment.

Remplace Mickey par n'importe quel logiciel sous licence très permissive et Disney par son auteur et tu verras que ton argumentation ne tient pas la route…

En plus, ce n'est pas Mickey qui tomberait dans le domaine public, mais les premières œuvres où Mickey apparaît. C'est une nuance de taille. Mickey en tant que tel doit être protégé plus ou moins comme une marque.

En même temps, pourquoi implémenter fork()?

Parce que, sous Unix, c'est la seule manière de créer un nouveau processus ? Je peux modifier ma question si tu veux : comment implémenter une fonction aussi simple que fork() dans Windows ? C'est uniquement pour simplifier la portabilité de certains programmes (tous ceux écrit pour Unix) que je pose cette question.