TMD Style (Text Markup Dialect)

TMD Style (Text Markup Dialect)
coccinelle	15-Dec-2006/19:19:59+1:00
Je crée un nouveau thread sur le sujet. J'ai une nouvelle assez sympa. La gestion du highlight est fonctionne, même si elle est encore buggée. C'est toujours ici http://www.ladyreb.org/wiki/doku.php?id=tmdstyle Là, on peut commencer à s'amuser.
shadwolf	19-Dec-2006/10:03:27+1:00
Tres bo travail marco ^^ par contre en mode console on crame 8 + 15 Mo = 23 Mo de mémoire vive pour un tou petit texte du tout ... une doc de 20 pages c'est 5120 Mo de ram ?? Hihihihi je suis méchant volontairement. Surtout que comme je l'ai dit ca peut être améliorer en suivant les technique de clean face loading de RebGUI (en gros make font make face make edge a la sauce VID normal c'est une tonne de données pour rien T___T donc deja en passant ta widget en RebGUI on devrait gagner en vitesse de rendu et en taille mémoire) bon je vois que mon umble défi intellectuel t'a pationné et j'en suis ravi ^^ Je contaste avec plaisir que le curseur est parfaitement bien géré tout comme l'ajout de text cependant tu ne gère pas encore les 2 fonctionnalité qui pour moi posent un enorme probleme -> modification dynamique du style d'un bloc de texte selectionné -> insertion de texte d'une couleur diférente (en fait ce que fait MS Word dans ce domaine consite a formater le texte ajouter au format courant pour modifier le style du texte ajoute par selecion de celui ci puis modification des parametre du style appliqué a ce bloc de texte mais en fait on en reviens au 1 er point) sinon point de vue algorithmie 'jai vu que tu réalisait la liste des widgets puis que en calculait la position ces 2 boucle de traitement ne devraient en formée qu'une je pense. Voila sinon jolie travail encore un peu de boulot dessus pour le rendre encore plus sexy et on l'envoi a Ashley pour qu'il l'intègre dans RebGUI ^^ C'est Carl qui va po etre content lol
shadwolf	19-Dec-2006/12:00:03+1:00
Hum en y reflechissant j'ai compris pourquoi tu avais probablement sépare la gestion de la position des widget de la gestion du rendu -> a cause de la capacité de resize dynamique de la fenetre de saisie du texte ce qui te fait gagner encore un bon point pour un portage sur rebGUI ^^
coccinelle	20-Dec-2006/11:05:53+1:00
Si Carl est pas content, il fera une annonce pour tuer l'oeuf dans la poule comme à son habitude.
shadwolf	21-Dec-2006/13:44:38+1:00
Bof moi j'aime bien ce challenge intellectuel en tout cas puis on montre qu'avec quelques bonnes idées on arrive a faire un truc qu'on attend deja depuis 1 ans. Moi je te soutient marco ^^ et en tout cas je vous felicite pour votre solution a ce problème. Tiens que pense tu d'inserrer le "carbage collector" que Francois Jouen nous avais fait (free-mem) Ca permettrai de virer de la mémoire un packet de données de transition non ?
coccinelle	22-Dec-2006/10:39:03+1:00
Pour l'instant j'ai surtout envie de faire fonctionner la chose. Je vais m'attaquer d'abord à gerer le curseur au clavier (flèche gauche, droite, etc...) ainsi que de transformer le dialect de manière à simplifier la modification du text (font, bold, etc...). Dites-moi ce que vous pensez de ceci : - un word! (par exemple bold) s'applique au texte qui suit - une paire issue! ... refinement! (par exemple #bold ... /bold) s'applique à tout ce qui est entre les deux balises. Voici un exemple plus complet : [ "Ce text est normal" #bold "Ce texte est gras" italic "Ce texte est gras et italique" "Ce texte est seulement gras" /bold "Ce text est normal" ]
guest2	22-Dec-2006/15:44:54+1:00
Dans l'absolu il faudrait accepter les dialectes qui emploient des blocks imbriqués sinon on aura du mal pour parser du Rebol. je reconnais que ça complique ennormement la mise à jour du source par rapport aux modifications faites graphiquement dans le RTE. Pour ma part je bosse toujours sur un parseur reversible qui prendrait en compte cette problématique, mais c'est pas facile.
coccinelle	22-Dec-2006/18:03:44+1:00
Je ne suis pas vraiment d'accord avec toi. Parser ce que je propose ci-dessus est un peu plus compliqué que des blocs imbriqué, mais si peu, si peu. Non, ce qui est plus difficile, c'est de décider ce que l'on fait dans ce cas : [ #bold #font [style [bold italic]] "Mon beau sapin, roi des forêts" "Que j'aime ta verdure !" "Quand par l'hiver, bois et guérets" "Sont dépouillés de leurs attraits" "Mon beau sapin, roi des forêts" "Tu gardes ta parure." /font "Toi que Noël planta chez nous" "Au saint anniversaire," "Mon beau sapin, comme il est doux" "De te voir briller par nous," /bold "Mon beau sapin tes verts sommets" "Et leur fidèle ombrage" "De la foi qui ne ment jamais" "De la constance et de la paix." "Mon beau sapin tes verts sommets" "M'offrent la douce image." Le deuxième couplet, il est bold ou pas ?
guest2	22-Dec-2006/18:41:25+1:00
De tout façon la grammaire que tu proposes n'est pas plus simple que les blocs imbriqués, au contraire même il faut gérer des balises de fin différentes en fonctions de l'attribut de groupage envisagé. Autant garder les blocs imbriqués, c'est quend même plus clair. [ bold [ italic [ "Mon beau sapin, roi des forêts" "Que j'aime ta verdure !" "Quand par l'hiver, bois et guérets" "Sont dépouillés de leurs attraits" "Mon beau sapin, roi des forêts" "Tu gardes ta parure." ] "Toi que Noël planta chez nous" "Au saint anniversaire," "Mon beau sapin, comme il est doux" "De te voir briller par nous," ] "Mon beau sapin tes verts sommets" "Et leur fidèle ombrage" "De la foi qui ne ment jamais" "De la constance et de la paix." "Mon beau sapin tes verts sommets" "M'offrent la douce image." ] Et tant qu'on y est , je vois pas l'intérêt de séparer les lignes, autant éviter le recours à des blocks inutiles et écrire: [ bold [ italic {Mon beau sapin, roi des forêts Que j'aime ta verdure ! Quand par l'hiver, bois et guérets Sont dépouillés de leurs attraits Mon beau sapin, roi des forêts Tu gardes ta parure.} {Toi que Noël planta chez nous Au saint anniversaire, Mon beau sapin, comme il est doux De te voir briller par nous,} ] {Mon beau sapin tes verts sommets Et leur fidèle ombrage De la foi qui ne ment jamais De la constance et de la paix. Mon beau sapin tes verts sommets M'offrent la douce image.} ] Mais je voudrais vous proposer une autre grammaire qui ne fait plus du tout appel aux blocs ou autres balises début/fin. Tous les changements d'attributs sont globaux et resaisir une 2nd fois un même attribut l'annule. Je reprends le même exemple: bold ; tout est bold italic ;tout est italic {Mon beau sapin, roi des forêts Que j'aime ta verdure ! Quand par l'hiver, bois et guérets Sont dépouillés de leurs attraits Mon beau sapin, roi des forêts Tu gardes ta parure.} italic ; enlève l'italic {Toi que Noël planta chez nous Au saint anniversaire, Mon beau sapin, comme il est doux De te voir briller par nous,} bold; enlève le bold {Mon beau sapin tes verts sommets Et leur fidèle ombrage De la foi qui ne ment jamais De la constance et de la paix. Mon beau sapin tes verts sommets M'offrent la douce image.} C'est une idée, après tout, le dialecte DRAW aussi gère toutes les modifications de façon globale alors pourquoi pas s'en inspirer.
DideC	22-Dec-2006/19:47:40+1:00
Je me suis déjà posé ces questions. Ma réponse alors étant d'utiliser des word! différents pour le début et la fin : bold "c'est en gras" italic " et en italique," no-bold " puis seulement en italique." no-italic " Et là c'est normal." D'ailleurs le dialecte RTD accepte une version "abrégé" de ces mots. Du coup ça devient : b "c'est en gras" i " et en italique," nb " puis seulement en italique." ni " Et là c'est normal." Le principal avantage étant de rendre les données du dialecte plus économes en octets, pour leur stockage sous forme texte. Je ne vois vraiment pas ce qu'il y a de compliqué à faire ainsi : quand on trouve 'bold, on met l'attribut 'bold dans la police utilisée et quand on trouve 'no-bold, on l'enlève. Il faut simplement mémoriser que la police a changé et emettre une instruction 'font dans le block Draw avant la prochaine instruction 'text. Ainsi, on peut enchainer différents instructions RTD touchant la police et n'avoir une instructions Draw/font qu'une seule fois. exemple : RTD: [ font "Arial" 15 bold "Le bon dialecte TMD existe t'-il ?" return return no-bold 12 "Tel est la question !" return ] ; Donnera en code Draw Draw: [ pen 0.0.0 font make object! [...] ; police "Arial" taille 15 en gras text 2x2 "Le bon dialecte TMD existe t'-il ?" font make object! [...] ; police "Arial" taille 12 text 2x38 "Tel est la question !" ] D'ailleurs quel est l'intéret de proposer plusieurs méthodes pour décrire la police (dans ton cas, Marco, par 'bold #bold /bold et par #font [style [bold italic]]) ?? moins il y a de combinaisons et plus le dialecte sera simple !
DideC	22-Dec-2006/19:59:31+1:00
Comme élément de réponse à la question de "Guestou" (ouh, c'est chou !) ou guest2 pour ceux qui n'ont pas compris, je pense que Marco a mi chaque ligne dans un string! différent car Draw ne gère pas les sauts de lignes dans le texte (ou alors ça a changé). Il est plus simple d'avoir des données TMD annonçant les sauts de lignes directement que d'aller les chercher dans chaque string! par un deuxième parsing. Perso, je les indiques dans RTD par 'return ou seulement 'r. Mais c'est vrai, que c'est laborieux d'avoir à tous découper. Même si c'est facilement automatisable.
coccinelle	22-Dec-2006/20:10:46+1:00
Moi aussi, je ne vois pas l'intérêt de séparer les lignes, c'est simplement parseque j'ai tapé le texte n'importe comment. Pourquoi je trouve complqué les blocs imbriqués. Parque imagine que l'utilisateur sélectionne du texte qui commence en dehors d'un bloc et qui s'arrète au milieu d'un bloc. Prenons un exemple : [ "Mon beau sapin, roi des forêts" bold [ font "Verdana" "Que j'aime ta verdure !" "Quand par l'hiver, bois et guérets" ] {Sont dépouillés de leurs attraits Mon beau sapin, roi des forêts Tu gardes ta parure.} ] L'utilisateur sélectionne "forêts Que" et le met en italic, on devra obtenir : [ "Mon beau sapin, roi des " italic ["forêts" bold [ font "Verdana" "Que" ] ] bold [" j'aime ta verdure !" "Quand par l'hiver, bois et guérets" ] {Sont dépouillés de leurs attraits Mon beau sapin, roi des forêts Tu gardes ta parure.} ] Alors que sans bloc, cela ma parait un peu plus simple quoique ce n'est pas sur: [ "Mon beau sapin, roi des forêts" #bold font "Verdana" "Que j'aime ta verdure !" "Quand par l'hiver, bois et guérets" /bold {Sont dépouillés de leurs attraits Mon beau sapin, roi des forêts Tu gardes ta parure.} ] Devient : [ "Mon beau sapin, roi des " #italic "forêts" #bold #font "Verdana" "Que" /italic " j'aime ta verdure !" /font "Quand par l'hiver, bois et guérets" /bold {Sont dépouillés de leurs attraits Mon beau sapin, roi des forêts Tu gardes ta parure.} ] Par contre, je n'aime pas que le même tag change de signification en fonction de la parité de son ordre d'apparition dans le texte.
coccinelle	22-Dec-2006/20:41:34+1:00
Didier, Je suis allé à table avant de finir mon post et je n'avais pas vu les tiens. Je gère automatiquement les sauts de ligne, ce n'est pas pour çà que j'avais séparé les choses. J'ai simplement écrit les choses sans réfléchir. Par contre, je ne coupe pas encore les lignes entre deux mots, c'est pour bientôt. Le dialect est tout à fait provisoire, je l'ai imaginé en m'inspirant de la proposition de Carl surtout pour tester différent cas et je suis d'accord avec toi, il vaut mieux éviter les choses redondantes. Le couple #bold ... /bold ou bold ... no-bold, c'est qu'une question de convention mais c'est pareil. Par contre j'aimait bien l'idée de Carl des mot qui ne s'appliquent qu'au texte ou au bloc qui suit sans balise de fin. Tout ça me fait penser qu'il y a un antagonisme entre l'écriture d'une source et l'édition wysiwyg. Pour faire au plus simple, on pourrait oublier l'idée de Carl des mot qui s'appliquent au texte ou au bloc qui suit qui va dans le sens d'un source simple, pour un jeu de balise qui modifient le texte au fur et à mesure de leur apparition comme tu le proposes.
guest2	22-Dec-2006/21:54:49+1:00
ben oui, c'est clair, le truc de Didec est plus simple. je plussoie ! Et c'est vrai que les string! sans newline c'est plus facile à gérer même si ça rend le source plus verbeux. Mais, n'oublions pas que dans dans une optique plus généraliste, il faudra bien savoir gérer un jour des string! complet avec sauts le ligne et tabulations intégrées même si ça complique le parseur. Ce serait dommage d'être incapable d'ouvrir un bête fichier txt ou même un rtf (pour plus tard).
DideC	22-Dec-2006/22:19:47+1:00
Je plussoie c'est quel verbe ça ? En tout cas j'aime bien Evidemment, il faut que le style permette d'afficher un texte simple. Si c'est déjà dans le parseur, alors... Sinon, une petite fonction 'load-text qui peut faire partie du style peut facilement faire la conversion. J'en ai fait une pour RTD, qui est dans cette doc (non terminée) à la page "principe" : do-thru http://membres.lycos.fr/didec/rebsite/styles/rtd-style/rtd-styles.r do-thru http://membres.lycos.fr/didec/rebsite/styles/rtd-style/rtd-style-doc.r Pour l'édition WYSIWYG, c'est sure que sans les blocs ce sera quand même plus simple. Il faudra "simplement" une petite fonction de nettoyage pour enlever les chaines vides, les balises identiques à la suite et les balise début/fin accolées.
guest2	22-Dec-2006/22:28:51+1:00
Je plussoie, du verbe plussoyer (Aie!) - être d'accord avec quelqu'un, mettre un "plus" à ce qui vient d'être dit, verbalisation de l'expression "+1" souvent utilisée sur IRC. dixit Maître Capello
DideC	22-Dec-2006/22:32:41+1:00
Je ne connaissais pas le verbe On en apprend tous les jours.
guest2	22-Dec-2006/22:39:09+1:00
Et encore, tu connais pas son corrolaire, le verbe moinsoyer (Aie ! mes oreilles) Bon, je sais pas si ça sera un jour dans le dico, mais on peut toutjours faire du lobying auprès de l'académie française. Des volontaires ?
DideC	22-Dec-2006/23:03:51+1:00
Hum, je crois que j'aurais pû le supputer Sur ce, créons un thread de circonstance...
shadwolf	24-Dec-2006/2:27:08+1:00
idée folle a 2 francs mais apres totu c'est noêl vive les esprits audacieux... pourquoi ne pas stocker les infos dans une table HASH on aurait un chiff^re ou un offset puis le texte example X= 0=Normal 1 = bold 2 = italic 3 = bold 4 = underline Y= taille du text make hash! [ 1x12 "un test en gras" 0x24 "la c normal mais en taille 24" 2x8 " c'est en italic mais trop petit !!!" 4x18 "Moi je suis un titre etc..."] cela faciliterai peut etre la localisation des données dans la table en fonction du contenu de la table de hash on peut aussi encoder la position de la widget dans le document (pour des sauts de ligne par example ou une meilleure gestion des paragraphes ) je connais pas assez hash! pour savoir si on en tirerai un réel avantage par rapport a une solution basée sur du texte pur.
shadwolf	24-Dec-2006/2:36:23+1:00
cela faciliterai peut etre la localisation des données dans la table en fonction du contenu de la table de hash on peut aussi encoder la position de la widget dans le document (pour des sauts de ligne par example ou une meilleure gestion des paragraphes ) cela faciliterai peut etre la localisation des données dans la table de hash en fonction du text de la widget (dans le cas d'une modification de contenu ou de style...) on peut aussi encoder la position de la widget dans le document (pour des sauts de ligne par example ou une meilleure gestion des paragraphes ) a ce momment la 324x300300 ca positionnde le texte en 300x300 ca le met en bold de taille 24
shadwolf	24-Dec-2006/2:42:02+1:00
>> foreach [off data] a [probe off probe data] 1x12 un test en gras 0x24 la c normal mais en taille 24 2x8 c'est en italic mais trop petit !!! 4x18 Moi je suis un titre etc...
coccinelle	24-Dec-2006/10:07:23+1:00
Petit réveil dominical : Attention, les string! se glissent facilement dans la rimaie des écrins. Dans ce cas, il faut suivre la voie du dôme toujours bien tracée jusqu'au début de la traversée finale. On se trouve alors à l'aplomb du couloir. Attention, la rimaye peut-être parfois difficile. Remonter le couloir puis suivre les arêtes jusq'au sommet. A la descente, restez bien sur le fil de l'arête pour éviter les chutes intempestives. Plusieurs rappels sont nécessaires puis il faut quitter le fil et emprunter un chemin très instables et arriver au dessus de la brêche. Ce n'est que là que la victoire peut s'obtenir à l'arraché et découvrir ce que les string! nous cachent si peu.
Goldevil	24-Dec-2006/15:00:24+1:00
Shad, je pense qu'il fait dissocier un format interne utilisée par la routine d'affichage d'un format de description que l'on retrouve dans un script ou un fichier texte. Ton idée de hash! est sympa et, je suppose, peut considérablement accélérer certains types de traitement. Mais autant l'éviter dans un dialecte de description. J'imagine assez bien un truc du genre source (format TMD) --> Conversion --> format interne (hash!) --> affichage L'avantage d'un hash, c'est la possibilité de trouver très rapidement certaines choses : - des indicateurs de styles - des numéros de lignes - du texte ... Je pense qu'un search & replace fonctionne vite avec une table hash!. Autre idée. Pourquoi pas permettre d'utiliser également des balises html b, pre, i, font color=red,...
guest2	24-Dec-2006/17:20:43+1:00
mouais, moi j'envisage plutôt l'utilisation d'une list! pour le format interne histoire d'être performant en insertion/suppression. et par rapport au type block! ou hash!, list! a un énorme avantage dans le cas qui nous concerne. Les variables qui pointent sur une liste ne sont pas dépositionnées quand une donnée est insérée ou suprimée plus haut dans la liste. Et c'est une faculté qui me semble absolument indispensable pour faciliter la gestion du format interne.
coccinelle	26-Dec-2006/9:42:18+1:00
Je crois que pour avoir de bonnes performances, il faut surtout éviter de faire des choses inutiles et c'est là que sont les vrais difficultés. Par example, si le curseur est déplacé, il ne faut que redessiner le curseur. Si la zone highlight change, il ne faut changer que celle-là. Idem si le texte est modifié, il ne faut redessiner que les lignes modifiées. Rien qu'à y penser, je me dis que ce n'est pas simple mais ce sera le prix pour obtenir des performances correctes sur de gros textes. Il faudra probablement maintenir tout une série de pointeur (pointeur sur le source, sur les lignes, sur les éléments d'une ligne, sur le draw) et j'imagine que les list! seront utiles dans ce cas.
guest2	26-Dec-2006/14:30:55+1:00
Mais de quoi parle-t-on ? faut pas confondre le redessinage du block Draw (invoqué lors du refresh) et la reconstruction des instructions Draw. Si tu parles d'optimiser la reconstruction des instructions, oui je suis d'accord, il faut éviter d'avoir à tout reparser et regénérer à chaque modification, les traitements devraient avoir un comportement incrémentiels. Mais en ce qui concerne l'opportunité de séparer texte, highlight, et curseur dans des faces différentes pour optimiser le refresh, là je suis plus circonspect. Ca posera pas de problème pour le curseur, mais pour la zone de highlight (pourquoi une seule au fait ?), on risque d'être obligé de placer une face transparante en surimpression et du coup je suis pas certain du gain (vitesse et mémoire), faudra faire des tests...
guest2	26-Dec-2006/14:45:25+1:00
... au niveau perf, je crois surtout qu'il faudra être capable de ne pas charger tout le document et de le parser petit à petit pour ne construire que ce qui est affichable. Je travaille sur cette question mais j'avoue que c'est pas simple car ça dépend de la grammaire du dialecte. Par exemple il est facile d'interrompre le parseur avec le ce que propose Didec, car il n'y a pas d'inclusions de blocs. On peut donc se repositionner facilement dans le source pour parser ou reparser les parties à afficher. Mais par contre, il pratiquement inenvisageable d'interrompre la parsing lorsque on a à faire à des règles récursives comme dans les dialectes avec inclusion de blocs. C'est pas impossible mais ça risque au final de produire des parseurs super compliqués afin de gérer le repositionnement. Plus j'y réflechis et plus je me dis que que pour faire un truc vraiment performant on risque d'accoucher d'une usine à gaz.
Goldevil	27-Dec-2006/1:33:03+1:00
J'abonde dans le sens de Guest2. Parser qu'une partie du code source pour se limiter à l'affichage que de ce qui doit être affiché est vital pour les performance mais peut-être ardu. A ma connaissance, les systèmes WYSIWYG (un traitement de texte comme un navigateur) utilisent toujours un format interne qui est fort différent du format de fichier. Si mes souvenirs sont bons, le logiciel fait un parsing allégé de tout le document pour produire un tableau de pointeurs. La coordonnées de ce tableau permet de lier une coordonnée x avec un pointeur vers le source à parser équivalent. Exemple, le document fait 1500 pixels de haut et je dois afficher de 850 à 1300. Dans le tableau, je sais directement quelle portion du code source je dois analyser pour l'affichage. De plus le tableau, contient aussi les attributs du texte à la position de départ. Par exemple, je sais que le texte est en bold, même si c'est définit plusieurs paragraphes plus haut que le début de la zone à afficher. En pratique, il y a donc 2 parsings différents. Un système d'analyse de tout le document et un système d'affichage d'une partie. Le premier génère une table de références. Evidement, au fur et à mesure de la frappe, le système doit changer dans la table de référence tout ce qui est derrière. En pratique, ça va très vite sauf pour une chose: le changement de dimension X (largeur). Il faut refaire une analyse de tout le document ou alors utiliser des ruses de sioux du genre le moteur Gecko de mozilla. Pour revenir à la remarque des Guest2, je pense que le dialecte qui est traité pour l'affichage doit être conçu pour les performances et non pas pour la lisibilité. Restera ensuite à faire une routine de chargement/conversion (avec parse). Et puis cette architecture facilitera l'affichage d'autres formats (HTML, MakeDoc2, postcript, rtf, pdf, ...).
guest2	27-Dec-2006/3:50:44+1:00
Oui Goldevil je suis sur la même longueur d'onde que toi pour la table de référence qui permet de construire uniquement ce qui est affiché. Par contre , je reste convaincu de la nécessité de mettre au point un parseur qui permette la description de n'importe quel dialecte (je travaille en ce sens). D'ailleurs ce que tu proposes, une étape de parsing intermédiaire pour construire un dialecte efficace, ne fait que consommer des ressources supplémentaires sans réellement résoudre le problème de fond (à mon avis) qui est la reconstruction du source à partir des données modifiées par le Widget. N'oublions pas également qu'optimiser la partie construction des données draw n'est pas suffisante, il faudra probablement mettre au point un loader de source qui fonctionne de la même manière (itérative). Car à quoi sert d'optimiser la gestion de l'affichage Draw, si on est obligé de charger la totalité du source en mémoire par un load classique avant de parser. J'imagine pour ce faire une notion de chargeurs en cascade Le premier ouvre le fichier sous forme de port. Le second charge (load) une partie du dialecte à partir du port source. le 3ième (parseur) construit une la représentation interne des données à partir des données dejà loadées. Et pour finir on construit les instruciions draw. Les appels se font en cascade et sont pilotés par le widget qui indique quand le chargement doit cesser (page écran remplie) ou reprendre ailleurs (déroullement de l'ascenseur). Si on reprend l'idée de Goldevil, on devra probablement gérer le repositionnement en créant une table de référence pour chaque niveau. La granularité (ou le pas entre 2 référence) des tables d'indexation devra être paramétrable à partir du widget, par exemple on devra pouvoir le fixer à 1/2 demi page. ce qui signifie qu'au pire on construirait en trop (1/2 page - 1 ligne) lors d'un repositionnement de l'affichage. Je sais pas si c'est claire, mais j'me comprend
guest2	27-Dec-2006/3:55:53+1:00
Oulaaa, promis la prochaine fois, j'évite les fautes ! - Bon! vais me coucher moi !
Didec	27-Dec-2006/12:41:44+1:00
Idée (juste une idée) : le format interne c'est le block de donnée Draw !! Il y a tout dedans : les instructions 'text sont suivi des coordonnées (position), donc on peut assez facilement trouver un texte. D'ailleurs on peut ajouter un 2ème pair! (ex: text "salut" 20x20 35x14) qui représenterait la taille du texte, Draw ne s'en ofusque pas et l'ignore. On maintient des pointeurs sur les premières instructions affichées et les dernières (pour ne pas tout reparser lorsqu'on cherche un offset, par un simple 'parse ou une boucle ['find Draw 'text]). Un autre pointeur Pour la position du curseur. Celui-ci peut être affiché par un 2ème block Draw dans le même block 'effect, pour éviter de faire des insertion/suppression des instructions d'affichage du curseur dans les "données" Draw du document. Déplacement du curseur = changement des 2 coordonnées de l'instruction 'line ou 'box. On peut même imaginer d'avoir 3 blocks Draw : 1 pour les données sauf la ligne en cours, 1 pour les données de la ligne en cours, 1 pour le curseur. Reste plus qu'à avoir un parseur qui génère un source TMD à partir des données Draw. Facile, non ? Bon ok, c'est peut être pas si simple ! Mais c'est juste une idée !
guest2	27-Dec-2006/14:18:11+1:00
Oui, c'est vrai que ça ferait des économies de ressource mais d'un autre côté certains aspects risquent d'être plus difficile à gérer faut bien y réflechir. Par exemple, dans mon cas, les objets internes conservent un pointeur vers la partie du source (en mémoire) dont il sont extraits, ce qui permet lors d'une mise à jour dans le Widget de savoir exactement quelle partie du source il faut impacter sans à avoir à reconstruire tout le source. Ca peut paraitre luxueux de vouloir faire des mises à jour partielles du source et non pas globales (en reconstruisant tout lorsque on quitte le widjet) mais mon but et d'avoir un source (en mémoire) synchronisé en temps réel avec le widget. Pour quoi faire ???? Et bien imaginez qu'on est pas une seule vue (un seul widget) pointant sur le source mais plusieurs en même temps... Réflechissez également à la façon dont vous pensez gérer l'annulation de séquences de modifications à partir d'un historique. Je vous laisse méditer...
guest2	27-Dec-2006/20:54:52+1:00
Apparement et pour continuer dans l'idée de Didec, Draw ne s'ofusque pas non plus de blocs insérés au hasard entre les instructions valides, donc pas de problème pour stocker des infos supplémentaires. A creuser...
guest2	29-Dec-2006/18:18:51+1:00
Hello, c'est calme en ce momment... Je progresse bien sur mon parseur réversible. Donc, je rappelle le principe: Le parseur parse (sic) une source et construit une liste d'objets internes. Inversement, si on modifie les objets internes et qu'on les réinjecte dans le même parseur, le parseur modifie le source en conséquence et uniquement la partie modifiée. L'intérêt, c'est que le format des objet internes ne variant pas, il suffit juste de fournir d'autres règles au parseur pour générer une source différente. Ainsi on pourra facilement (j'éspère) faire des conversions d'un format à l'autre. Aujourd'hui le dialecte utilisé par mon parseur ressemble à quelque chose comme ça: ; define constants section ; usage of values in dialect are prohibited, define them as constant before use. b: cons ['bold] i: cons ['italic] u: cons ['underline] police: cons ['police] no: cons ['no] tuple: cons [tuple!] integer: cons [integer!] string: cons [string!] ; rules and sub rules ; All words in capital letters are reserved words my-grammar: [ PUSH ;to make all following font settings locals any [ police FONT-NAME string \| FONT-COLOR tuple \| FONT-SIZE integer \| b BOLD \| i ITALIC \| u UNDERLINE \| no [b NO-BOLD \| i NO-ITALIC \| u NO-UNDERLINE] ] TEXT string POP ;to delete current font settings and get the previous ] my-grammar ;last instruction return the global parser block. Impressionnat non ? le même dialecte sert à construire les instructions draw et à modifier le source. Bon j'y retourne...
shadwolf	31-Dec-2006/0:07:43+1:00
oui c'est une tres bonne idée guest2 ^^ J'ai lu ce que proposait gold evil et en fait moi je proosait HASH pour eviter de "parser" justement moi mon ut ca a toujours été MakeDoc/MakeDocPro -> format randerisable interne (peux étre hash! ou mini dialect TDM ) -> DRAW -> ecran bon que ce soit en hash ou en mini dialect TDM ca change pas trop en fait faut quand meme se tapper l'etape transformationau dialecte draw. D'ailleurs dans MDP-GUI ou MD-Viewer on a : MakeDoc/makeDocPro -> compositing VID (avec widgets minimalistes préchargées) A mon sens Hash! avait un interret dans le cas accès aux données du format de transition (etape avant conversion des données au format draw) pour modifier le contenu rapidement ( soit au niveau du format soit au niveau du contenu du text ou de sa mise en forme) enfin comment faire pour que seulement la partie visible soit renderisée ... Je m'explique amon avis le moteur le plus rapide c'est celui qui crée les données de transition pour tout le document mais ne creé les données draw que pour la portion du cocument actuellement visible a l'écran. La je suis entièrement d'accord avec DideC. on economise sur ce qui est le plus important dans ce genre d'application la vitesse de rendue et le segement de mémoire alloué au instructions draw!. Sur un document de 200 pages il est plus facile de ne dessiner a l'écran une demi page de document plutot que toutes les 200 pages du document. Même si ce n'est pas une préocupation immédiate pour le momment il faut quand même avoir ce but a atteindre comme Saint Grall pour le meilleur moteur de rendu possible. Dans cette optique a mon sens mais bon la je peut me tromper le format de données de transition pré-draw! doit être accéssible rapidement et suffisement bien organisé ou segmenter pour que l'on puisse se dire que je vais dessiner a l'ecran que la portion de texte que l'utilisateur consulte example de l'offest 0x100 a l'offset 0x400 pour une fenetre de visionnage qui ferrait 300x300 mais on doit aussi tennir compte du fait que suivant la taille de la police on peut avoir 300 pixel en Y ca peux représnter 30 lignes si la taille de la police est de 10 pixels ou 10 lignes de text si la taille de la police est de 30 pixel et dans ce cas hash! me semblait tout à fait adapté. on peut aussi voir hash! que comme le collecteur et avoir au lieu de données offset (codé) text une structure de donnnées offset de position de la widget ( information hyper importante pour n'avoir a dessiner que la portion visible du document) puis un objet simplifier du type font voir meme carement l'objet face/font lui même comme ca on a pas a retraduire les données de la font en draw on cole simplement la donnée issue de la table de transition Dans le cas d'un ajout de données différentes en plein milieu d'un bloc existant on ajouterai simplement la nouvelle données a la fin de la table de transition (hash!) puis on localiserait les données de la ligne ou se trouve le curseur du on couperait cette donnée en 2 données dont les offset serraient de part et d'autre de la nouvelle données (on applique un sort rapide sur la table de ash! pour remettre calsser les données en fonction de leur offset (bien que normalement le but d'une table de hashage en C ce soit justement que la prémiere données servent d'index et que par conséquent la table soit automatiquement triées dès l'insertion de nouvelles données dana la table en rebol ca marche pas comme ca c dommage ...) example make hash! [ OxO [ t: "un texte long" f: make face/font [....] ] 0x70 [t: none f: none ] 0x80 [t: none f: none ] 0x90 [t: none f: none ] 0x100 [t:"encore du texte c tres tres long" f: make face/font [....]]]] pour résumer les avantage sont: 1) taille des données de transition allégées 2) localisation rapide de portion de données 3) manipulation rapide des données 4) Traduction en Draw rapide et ne necesitant pas une etape sulémentaire de parse (on a déja une etape de parse lors du chargement des données provennant du document Format document -> Format de transition. Ce serrait génial de ne pas avoir encore un parse apres ca mais juste une etape récupération des données et composition des données Draw!
guest2	31-Dec-2006/5:18:36+1:00
béh j'ai pas compris l'intérêt du hash dans les avantages ennoncés. Hash!, prend beaucoup de place en mémoire, plus que list!, et de plus il ne permet pas de conserver des pointeurs sur la liste qui ne soient pas dépositionnés par l'insertion ou la suppression dans le hash (même problème que block) Le seul avantage que je vois à utiliser les hash, c'est la recherche rapide, mais il n'y a aucune raison d'avoir à lancer des recherches pour la gestion normale du Widget. Sinon en ce qui concerne l'utilisation d'une représentation interne des données ou pas (indépendemment de la structure de données qui la contient) : C'est certain que le parseur pourrait directement produire les données draw mais j'essaye de voir plus loin. Les objets internes peuvent contenir les notions de paragraphe, saut de ligne, style, cadres, images, tableaux de façon ordonnées et hiérachisées, ce que le dialecte draw ne permet pas de décrire. Le but, encore une fois (enfin c'est je que je crois) , c'est de réussir à produire n'importe quel format externe (rtf, tmd, reboldoc, html) sans avoir à réécrire toute la mécanique propre au widget qui risque d'être assez hardue si on veut économiser de la mémoire et être performant. Pour l'instant vous n'envisagez que la transition source -> (affichage) Widget. Hors je suis persuadé (gràce au travail déjà entrepris) que la transition. Widget -> (regénaration) source est pratiquement impossible avec des séquences d'instruction draw non hiérarchisées. C'est pourquoi je pense qu'il sera très difficile de se passer d'une représentation interne distincte des séquences d'instruction draw.
Login required to Post.