COLORISATION SYNTAXIQUE ET VID
shadwolf26-Mar-2009/20:43:39+1:00
Bonjour a tous,
Comme on a digréssé et pouri le poste de ldci annoncant
son projet "small rebol" et que c'est vraiement pas gentil.
je tiens a m'excusé au près de ldci et des lecteurs de ce forum pour la gène occasionnée.

J'ouvre donc ce topic pour parler de la conception, l'amélioration, et la réalisation d'une face VID 2 (VID3 existant pas officiellement je code pas avec. Mais cependant je souhaite que cette face soit une face militante ( mwuhahaahaha ...) disons que mon but c'est de montrer que 1) c'est possible 2) on peut faire ca assez simplement 3) que ca nous permette de proposer des amélioration pour ce domaine particulier pour qu'elles soient intégrée dans rebol 3/ VID 3)

Ce projet me hante depuis quelques années et devant la tâche monnumentale il faut bien le dire je suis passé par des momment de fort doute et démotivation.

Ce qui a renforcé mon sentiment que dès qu'on sort des sentier battu avec rebol ca devient vite l'horreur.

Récement je me suis remotiver pour reprendre le projet.

Je vous propose donc ce nouveau script qui est vraiement un version de travail ( ca marche !!! mais bon loin d'etre optimal !)

http://shadwolf.free.fr/area-tdm01.r

pour réalisé ce projet j'ai mélanger un code de coccinelle et un code de carl sasenrath (conversion text en tdm)

Voila j'attend vos remarques (soyez pas timides ^^)
shadwolf26-Mar-2009/20:52:17+1:00
comment marche le script:
- enregistrer le dans un dossier
- lancer le script
- appuyez sur le bouton "open file"
- choisissez un fichier .r (script rebol) ca marche avec
ce script par example

C'est tou y a plus qu'a regarder le resultat dans l'area qui se trouve en bas.

L'implémentation est assez rudimentaire dans les jours qui viennent je vais amméliorer le code. cependant vous pouvez quand meme me donner votre avis ^^.
shadwolf26-Mar-2009/20:52:37+1:00
comment marche le script:
- enregistrer le dans un dossier
- lancer le script
- appuyez sur le bouton "open file"
- choisissez un fichier .r (script rebol) ca marche avec
ce script par example

C'est tou y a plus qu'a regarder le resultat dans l'area qui se trouve en bas.

L'implémentation est assez rudimentaire dans les jours qui viennent je vais amméliorer le code. cependant vous pouvez quand meme me donner votre avis ^^.
guest226-Mar-2009/21:50:42+1:00
j'ai essayé, ça semble super lent juste pour bouger le curseur.

Je donne quelques infos sur l'éditeur richtext que j'essaye de développer avec R3 en ce moment. Les choix que j'ai faits règlent pour le moment le problème de lenteur.

je pars d'un ensemble de règles de parsing contenues dans un fichier externe indépendant qui décrivent la syntaxe et les styles à appliquer du language markup cible.

Actuellement pour le dialecte makedoc1, j'en ai un qui ne fait pas plus de 2 ko.
Pour TMD, j'imagine que ce serait encore moins.
L'avange de ce design est évident, je n'ai pas besoin de toucher à l'éditeur pour traiter un langage markup différent. Il suffit de charger un fichier de règles différentes.

Ensuite à partir des règles de syntaxe et du texte, je construits un DOM (une structure de blocs imbriqués contenant les règles à appliquer sur chaque portion de texte.
Cette structure intermédiaire permet d'avoir une approche incrémentielle lors de la construction ou de la modification des objets graphiques contenant des portions de texte.
en effet, après modification d'une portion de texte à l'écran je suis capable de connaitre quelle sous règle doit être appliquée pour vérifier la syntaxe et pour modifier ou reconstruire l'objet graphique dans lequel je me trouve.

Cette approche est très rapide, car on pas à re-parser tout le texte ou de reconstruire tout les objets graphiques à l'écran.

Basiquement, chaque ligne de texte a son propre objet graphique (ça dépent des règles bien sûr).
Donc quand on modifie une ligne de texte, seule cette ligne est parsée puis reconstruite éventuellement.

Les styles à appliquer peuvent être associer à toutes les règles et sous règles.

C'est loin d'être au point mais j'ai déjà pu constater que les perfs sont au rendez-vous.
shadwolf27-Mar-2009/22:31:42+1:00
salut guest2,
pour les règles de parsing initialement je voulait les externalisées et créer dynamiquement les regles de parsing
'(en gros mettre dans un fichier a part des block avec les mots clef regrouper par catégorie puis charger ses mot clef et en faire le block de règle par manque de temps et surtout pour avoir un apperçu de ce que pouvait faire area-tdm dans ce domain j'ai choisi une approche de parsing bcp plus simple issu du script color-code de Carl Sassenrath. Peut de code veux dire et surtout quand on fait des choses aussi compliquées une plus grande facilité pour avancé)

Pour ce qui est de la lenteur de area-tdm une fois qu'on l'utilise avec bcp de texte. C'était une issue prévisible. J'avais d'ailleurs exposer ce problème inhérent au projet utilisant le widgets compositing. C'est pour cettre raison que je voulais prévilégier une solution uniquement basée sur draw/AGG et du parsing, le problème c'est que la gestion de texte dans draw/AGG est vraiement embryonaire. J'ai comparer recement avec d'autres support de texte dynamique comme scintilla par example et il apparait que la moindre des choses c'est de disposer des information de largeure et de hauteur pour chacun des caractere en fonction du format courant de la police de caractères ( j'ai meme vu une extension de AGG sur le site de l'auteur proposant ce genre de fonctionnalité mais uniquement pour win32Api (GetGlyph () ) pour les pationnés.)

Ceci dit avoir cette base de travail nous permet d'essayer de trouver des "raccourcis" pour accéléré le code.

je suis ravi d'apprendre que tu travailles actuelement a la réalisation d'un rich text editor pour VID3 cependant je me demande si tant qu'on ne dispose pas d'un vrai set de fonctionnalités de bas niveau dans draw/AGG pour le traitement de texte riche et dynamique on peut vraiement avancé dans le domaine.

L'idée d'eclater les données en mémoire n'est pas mauvaise mais ca a un coût aussi au niveau de la taille de la mémoire employée.

Pour ce qui est de la colorisation syntaxique le problème majeur est d'avoir à la moindre action de l'utilisateur a reparser tout le contenu en effet si j'ai if et que je supprime une lettre ou en rajoute une autre il faut que la couleur repasse a la coleur par défaut cet aspect dynamique plombera aussi les performances à terme.

Par example en TDM quand on déclare une ligne comme étant un titre tant que l'utilisateur ne selectionne pas toute la ligne et appui sur un bouton qui change le mode de cette ligne le mode ne change pas ausi on peut retirer tout le texte de la ligne et le changer par example le formatage de ce nouveau texte sera celui de la ligne courante. Cette démarche n'est pas applicable à la colorisation syntaxique
en effet si j'ai un "if" rouge ca que je l'efface que le remplace par un mot clef d'une autre catégorie la colorisation doit etre renouvellée au momment de l'action sur la barre d'espace, car c'est l'insertion de l'espace qui fait que le mot est consédérer comme complet, et la colorisation initiale du if ne doit pas se répercuter a ce qui suivra apres. Actuellement dans area-tdm si on ajoute du texte (la suppression de texte n'est pas supportée) la colorisation ne disparait pas, et est propagée a tout ce qui est ajouter a la suite de texte colorisé (ce qui est normal puis qu'on a scinder notre texte en sous bloque de texte pour leur appliquer la colorisation et que pour pouvoir calculer la position des différents éléments du texte on c'est servis de widgets dummies (on pourrait dire aussi cobaille :P ))

une alternative est de dire voila la font et taille du texte sont fixes et on se sert de ca pour faire un moteur 100% AGG cependant, il y aura de toute façon un problème quand on en arrive a modifier une ligne (il faudra la mettre a jour dans la structure de base puis répercuter ce changement dans draw)
l'idéal ce serrait une structure ligne a ligne ou le texte est atomisé.

[["a" 10x10 1 "b" 15x10 1 etc...]
["a" 10x10 1 "b" 15x10 1 etc...]
[]
]

avec le compositing widget si on atomise plus la structure ca reviens a créer autant de widget dummies que de lettre dans le texte ce qui va très vite etre un ennorme probleme (je veux meme pas voir 20 000 widgets dummies en mémoire lol)
shadwolf27-Mar-2009/22:36:15+1:00
Par example en TDM quand on déclare une
a remplcé par par exemple en Makedoc quand on déclare une ligne.... etc...
shadwolf27-Mar-2009/22:36:37+1:00
Par example en TDM quand on déclare une
a remplcé par par exemple en Makedoc quand on déclare une ligne.... etc...
shadwolf4-Apr-2009/1:53:07+2:00
j'ai un nouveau script exploitant une version simplifiée de rendering de Coccinelle.

Allez point de vue technique expliquons ce que je fais:
1) le text brute issue de du fichier que l'on charge est
converti en format TDM ( format de coccinelle en version simplifiée en utilisant une partie du script de CArl Sassenrath color-code )
2) a partir de la on crée une structure de "transition"
en exploitant size-text pour calculer la position du caractere suivant en fonction du caractère courrant et de
la taille de la font
3) la structure de transition est convertie en instructions draw puis ce block de donnée draw est transféré dans notre widget area-tc et c'est affiché a l'écran.

le résultat est vraiement vraiement bien je trouve.
(rapidité, lisibilité et fidelité du rendu par rapport au contenu initial)

L'embêtant c'est que ce n'est que du read only. Va falloir que je me creuse la tête pour gérer l'insertion/suppression
de texte.

Faudra aussi que j'améliorer les étappes de rendu y en a trop et que j'améliorer aussi le contenu draw.
shadwolf4-Apr-2009/1:54:06+2:00
Scrip en question en DL ici

http://shadwolf.free.fr/area-tc.r
shadwolf4-Apr-2009/14:39:20+2:00
Cette nuit nous avons beaucoup discuter sur altme et beaucoup codé avec Steeve et Maxim.
Je tiens a les remercier chaleureusement pour leur aide et leur soutient consernant ce projet

Voici le liens vers le script issu de notre co-ecriture nocturne.

http://shadwolf.free.fr/area-tc-01.r

je pense que ce script fait un grand bon en avant du point de vue des performance et de la qualité de l'affichage comparé a ce que j'ai proposer au part avant.

Il n'y tjrs pas de "text motion" cependant l'on peu scroller le text avec fleche du haut et fleche du bas ou la roue de la sourie.

je vais me concentrer dans les jours avenir sur la réalisation du texte motion.
shadwolf5-Apr-2009/6:19:55+2:00
comme le projet avance ennormement pour l'instant et que uploader sur mon ftp a fini par me fatiguer j'ai config un SVN spécialement pour host cette contribution

pour ceux qui ont pas de client SVN

http://my-trac.assembla.com/shadwolforge/browser

pour ceux qui ont un client svn

http://my-svn.assembla.com/svn/shadwolforge

Dans les jours qui viennent je publierait les mise à jour au fur et a mesure sur ce site et je ferrait une documentation "retour d'expérience" sur le sujet.
shadwolf5-Apr-2009/6:35:53+2:00
les nouveautés:
- amélioration du rendu draw (on ne désine que ce qui est affichage dans l'espace visuel de la face quand on scroll on ne traite qu'une seule ligne -- Amélioration par Steeve)

- On a un curseur motion assez convaincant

- On a le support page-up et page-down pour défilement rapide
(steeve)

- On a un joli ascenseur sur le coté droit de l'espace visuel de la face qui permet un scroll encore plus rapide.

- On a corriger et améliorer plein de d'autres petite chose au fur et a mesure.

Voila la suite au prochain numéro. On va attaque le vif du sujet l'insertion de texte dans une ligne a la position du curseur de texte (caret). Viendra en suite la suppression de texte dans une ligne la supression de lignes puis, le collage de ligne. l'insertion le de ligne avec gestion de la saisure de ligne existante.
Pour finir on essayera d'implementé aussi la selection de texte ainsi que le copier coller et la supersion de texte
sélectionné.
shadwolf5-Apr-2009/22:56:04+2:00
Pour notre plus grand plaisir le projet avance a pas de géant.

la version 03 d'area-tc dispo sur le SVN (svn browser pour le message d'update avec ce qui a changé)

Felicitons tous steeve pour son travail titanesque sur cette derniere version.

- refonte complete du processus de rendu
- gestion de l'insertion / suppression de texte
- colorisation a la volée du texte saisi
shadwolf7-Apr-2009/23:32:16+2:00
area-tc continu d'evoluer au menu des nouvelles choses proposée par steeve.

Onn a:
- gestion touche home et end pour se rendre rapidement a la fin d'une ligne
- ctrl+touche droite et ctrl + gauche pour passer d'un mot a l'autre.
- Grace aux conseils de cyphre le moteur de rendu est en moyenne 2 fois plus rapide qu'avant
- publication sur le wiki/track de l'histoirque de développeement
- insertion d'un scroll horizontal
- gestion de l'insertion de nouvelle ligne avec prise en compte de la saisure de ligne existante
- quand du texte est inserer en fin de ligne et que la ligne est plus grande que l'espace d'affichage la vue scroll automatiquement sur la droite.
- Code cleanage:
un gros travail de refonte et d'amélioration de l'ecriture du code a été faite.
- correction de bug inhérant au text cursor motion
- le script accepte de démarrer sans document chargé

on a énnormément avancé on attaque la sélection dynamique de text. Viendra en suite un historique des actions pour gerer le undo/redo.
ldci8-Apr-2009/1:46:37+2:00
Salut Shad
J'ai regardé le code qui avance super bien. Un petit problème cependant: sous Mac OSX aucun caractère ne s'affiche. Une idée?
shadwolf8-Apr-2009/2:09:33+2:00
Hooooo ... heu MacOS X c'est koi ? lol

Bonne blague mise a part on utilise du rebol pur jus. Ya rien dans le code a part du rebol du VID et du draw. Donc si ca marche pas ca viens certainement de la VM et que le portage e la VM R2/view est pas au top.

Si rien ne s'affiche c'est peut etre qu'aucun fichier n'est charger essaies en chargeant un fichier avec open.

sinon c'est au niveau de la pile draw/AGG on utilise text anti-aliased et c'est peut etre pas porter sur MacOS X.

C'est aussi tout l'interret de ce genre de projet pousser le dialect draw/AGG au maximum de ses possibilité pour voir si y a des défaut et si c'est le cas faire en sorte de partager l'information afin que R3 ne contienne plus ces défauts.

en ecrivant ces ligne une autre idée me vient ca vient peut etre de font-fixed (pour éviter d'avoir a calculer la position et la taille de toute les lettres on utilise une font de taille fixe) et donc font-fixed existe peut etre pas sur MacOSX R2/view
shadwolf8-Apr-2009/2:19:17+2:00
En discutant rapidement avec steeve il arrive a la meme conclusion que moi -> police font-fixed pas supportée sur MacOS X donc essai de changer le nom de la police dans l'objet font-obj dans area-tc ligne 356
shadwolf8-Apr-2009/18:49:04+2:00
Steeve a réaliser la selection de text au clavier et la sourie.

Selection de texte:
Maintenir le bouton gauche de la sourie enfoncé puis
déplacer la sourie de gauche a droite de haut en bas

Maintenir enfoncer la touche Maj et se servir des flèches pour activer la selection

Maintenir enfoncer les touches Maj + Ctrl pour faire de la
sélection mot par mot plutot que lettre par lettre.
Didec9-Apr-2009/10:21:01+2:00
Je viens de faire un test rapide : super bien.
Rapide, efficace, très fonctionnel.

Bravo les gars, super boulot.
Bravo Shad, t'as réussi à motiver les troupes !!
shadwolf11-Apr-2009/0:04:01+2:00
Merci DideC, c'est surtout Steeve qu'il faut félicité il a fait vraiement un travail ennorme.

Ce qui est un peu dommage c'est d'avoir 80% du code pris par la gestion du curseur et du texte motion.

Comme avec draw on descend vraiement au plus bas du bas niveau en terme de fonctionnalité on doit émulé completement le texte motion et c'est une vraie boucherie.

Mais ce n'est pas fait en vain (du moins je me force a le croire) ca permet de tester VID et draw dans des cas extremes ca permet de montrer que VID c'est mega puissant
ca permettra (je l'espere) dans le futur de données des idées de fonctionnalité plus sympatique dans ce domain a Carl pour les versions a vennir.

Il y a la un véritable potentielle à creuser.
shadwolf11-Apr-2009/0:05:55+2:00
françois tu as réussi a corriger le probleme d'affichage sur macOS X ?
ldci13-Apr-2009/13:23:40+2:00
Salut Shad
D'après ce que j'ai pu lire sur les versions Mac OSX; "DRAW (AGG) does not support fonts."
Effectivement le changement de font-fixed par font-serif ou autre ne marche pas. On a donc une limitation dans l'implémentation de AGG dans la version Mac. Jz crois qu'il y a des problèmes similaires sous Linux.
A +
shadwolf14-Apr-2009/3:51:03+2:00
merci pour l'information ldci ^^.
Je vais demander sur altme que cet aspect soit testé plus avant.
shadwolf22-Apr-2009/13:50:52+2:00
Cela fait un petit moment que je n'ai pas poster de nouvelles du projet ici.

Area-tc a beaucoup progressé depuis mon dernier post.
Area-tc offre actuellement une grande parties des fonctionnalités d'édition de texte usuelles.

Le plus gros de l'effort dans ce projet a été mis sur la réalisation de l'interface Home machine qu'il a complètement fallut écrire.

Pour ce qui est de l'avennir c'est a dire du passage au R3 je ne sais pas trop ce qu'apportera la widget ritch-text en préparation et resté au niveau le plus bas dans la chaine de rendu (draw/agg) me semble une bonne chose. Je serrai donc plus d'avis de faire progresser draw/agg et de fournir pardessus une widget d'édition de text multi-emploi. Un genre d'evolution de l'area actuelle ou on pourrait fournir un texte formater et une règle de parsing customisée adatée a ce format.
shadwolf28-Apr-2009/9:18:45+2:00
Le project area-tc connais un nouveau fork.

J'ai introduit la widget menu dans area-tc ce qui donne l'occasion a une version séparée.

Il vaut mieu séparer les version pour l'instant pour les tests et développement ne concernant que la partie du menu.

Sur le SVN area-tc-03-menu.r correspond a area-tc-03.r (v.31 de Steeve+ quelque ajout de ma part) + l'ajout de la barre de menu.
shadwolf28-Apr-2009/9:21:11+2:00
A terme area-tc-03-menu deviendra la version courrante.

Une fois que la stabilité et l'implémentation de la barre de menu seront validés.

Login required to Post.


Powered by RebelBB and REBOL 2.7.8.4.2