 |
| Au fait ... R3GUI RMA l'abandonne | |
| shadwolf | 10-Nov-2011/10:41:22+1:00 |
| Cette information vous a probablement echappé mais voici ou en est r3gui RMA: 7306 Robert Well, we all have a hell lot to do. There are just a some simple facts: - making public releases cost us time. Not horrible lot but anyway... - people are interested to take a look at the code and run the tests... - maybe we get some feedback All nice, but it doesn't move us forward faster. I'm not frustrated I'm just wondering.... there are still a lot of excuses why R3 can't be used (which is wrong) but only a very few people try to build something with it. 7307 Robert Anyway... we continue with our development but public releases will have lower priority. We are using our stuff to build some small tools, we will publish. Than you might take a look what's possible. 12-Oct 6:19 En gros RMA nous fait le coups du "oooooouh lala la on plein de chose a faire on va pas pouvoir continuer a publier" Ca me rappel quelque chose ... ... mais je me rappel plus quoi ... ... bref les codes Wizards qui avaient mis un an a sortir un fenetre qui redimensionne son contenu comme il faut jettent l'eponge normal quoi. | |
| shadwolf | 10-Nov-2011/11:07:56+1:00 |
| 10678 Henrik VID is however quite sparse, as it was written in a week, by Carl, a decade ago. There are some extensions and replacements available. 3-Nov 8:04 ---- au risque d'enfoncer le clou ... dans le cerceuil  ... Ca montre juste le gros gros manque de niveau de RMA.Ah et au risque de me repeter moi je participerait pas a une guignolade de ce genre... | |
| trigram | 11-Mar-2012/21:03:47+1:00 |
| Finalement, pas si sûr... http://www.saphirion.com/development/r3-gui/ Sur le twitter de RM Assest : "@rmasset: New R3-GUI source code version released. See: http://t.co/SH1MGo7s We use this one for our 1st Rebol-3 product." | |
| shadwolf | 16-Mar-2012/19:11+1:00 |
| super et ca donne quoi ? c'est toujours aussi nul ? ils ont changer quoi cette fois? Laissez moi devinez ... hummm ... la couleur des bouttons !!! vu leur niveau et le temps qu'ils passent dessus ca ne peut etre que ca. | |
| cr8825 | 19-Mar-2012/15:49:28+1:00 |
| hello, cela semble bien plus stable..... a première vu !!!!! de plus il faudrait arrêter de critiquer le travail "gratuit" des autres !!!!! merci | |
| shadwolf | 28-Mar-2012/18:17:27+2:00 |
| cr8825 tu oublis un peu vite que les premier a critiquer le travail "gratuit" des autres c'est Carl Sassenrath et RMA. Pour rappel le moteur view 3 de Gabriele Santilli et le fais que rebgui n'est pas survecu au passage a R3 tout ca pour avoir au bout d'un an et demi de travail une librairie graphique ne contenant pas un dizieme de ce que contenait rebgui et je suis meme pas certain que le passage de vid a gui soit un gain. Pour faire des interface moche pas besoin de r3/gui un tres vieux rebol/view 2.0 suffit largement. Ceci dit je les comprends a quoi bon faire evolué le gui si la VM rebol3 est plus maintenue. truc rigolo a faire sur r3 a:test: "test probe a:test ;P | |
| yos | 30-Mar-2012/11:53:08+2:00 |
| Salut, Pourquoi le moteur de GS et rebgui n'ont pas survécu à R3 ? Peut être le manque de modularité ? Depuis que j'utilise REBOL j'ai toujours voulu anticiper la portabilité des programmes aux versions futur du langage car sa syntaxe et sa structure (objet system) pouvaient changer à tout moment. Les 2 seules chose fixes dont j'ai besoin pour programmer sont : 1 - un context pour loger mes mots 2 - un endroit privé dans chaque face (composant unitaire graphique) typiquement le user-data de l'objet face. Avec ces 2 petites choses et un peu de créativité j'ai toujours réussi à faire ce que je voulais avec R2: -Ajout de menus contextuel à n'importe quelle face (principal ou composant à l'intérieur du layout) -utilisation du croché parent-face pour naviguer dans la hiérarchie des faces et/ou utilisation d'une couche événementielle maison pour récupérer comme dans les feel fonctions directement les objets face et les events reçus. (pas de nouveau crochet comme parent-face je crois que rebgui apporte une nouvelle structure et je trouve celà trop compliqué pour moi). Aussi j'ai commencé à factoriser mon code en fonctions utilitaire et maintenant je factorise aussi la création d'objets graphique. Par exemple une calculatrice complète est un style affichable plusieurs fois dans une même layout ou dans plusieurs layout séparées mais dans la même VM. Dans le cas de la calculatrice il faut que le moteur de calcul soit étanche d'une calculatrice à l'autre (un clear sur une ne le fasse pas sur les autres). J'ai travaillé plus cet hiver sur mon framework pour finaliser l'interface pour le programmeur et la gestion des requester et maintenant je vais m'attaquer à la création de composants graphiques plus complexe pour tester cette interface. Pour moi REBOL est 1 machine et tous mes programme doivent tourner en même temps en asynchrone (plus d'utilisation d'inform car arrêt de la boucle d'évenement) Comme exemple je voudrais modulariser l'editeur intégré de REBOL car le code ne me plait franchement pas (comme le request-date que j'ai modularisé en premier avec composant graphique peeker et barre des jours etc...). Je pense que R3 montre bien une évolution vers plus de modularité que R2 mais j'aurai préféré que Carl S. se concentre sur le minimum vital (performance dialect et modularité) de manière à laissé la communauté faire les composants graphiques. J'attend que Red me donne le composant face de base avec un user-data pour tester mon framework dessus mais ces toujours avec passion que j'utilise R2 chaque hivers !! A+ Yos | |
| shadwolf | 10-Jun-2012/7:54:52+2:00 |
| heu non c'est pas du a un manque de modularité... bon rebgui a eu une evolution ... hum comment dire ... sans froisser personne. Au et puis zut je suis pas equipé du mode tacte donc je vais faire comme d'hab dire la vérité et me mettre tout le monde a dos. Don rebgui a comment en etant ultra modulaire super ouvert une redefinition dans le bon sans de VID, la communauté rebol prevoyait meme serrieusement de pousser rebgui pour qu'il soit intégré a la vm rebol par defaut... Et ce jusqu'a ce que deux choses se produisent 1) Ce bon Ashley a plus ou moins verrouillé rebgui en sur exploitant le concept de redefinition et optimisation de rebgui... tout ayant été réecrit on avait plus access a des choses triviale comme le control des events de maniere clean. Les events etait parasité par un tas de routines précablés au sein meme de rebgui ce qui a eu pour concéquence par exemple de faire que area-tc ne soit pas adaptable a rebgui. Puis Ashley s'etant enfermé dans sa propre compléxité a arrété de developer rebgui 2) car a annoncer un nouveau VID revolutionaire. Du coup les feignants qui composent la communauté rebol se sont dit chouette nous allons rien foute et carl va nous apporter un super vid nouveau vid avec tout plein de objects fantastiques dont la fameuse widget de text formaté ( genre ms word). Travail qui finalement n'a été qu'une ébauche avant que carl balance le project a rma avant de disparaitre. RMA a rien foutu comme prevu. heu rebol est un show room ... c'est une demo de ce qu'il pourrait y avoir comme autre facon de faire de l'informatique mais le probleme principal est que les concepteurs de logiciels ne sont pas payer des fortunes a travers le monde pour faire des logiciels qu'un chimpansé pourrait faire ... Oui bon j'exagere mais franchement rebol c'est toujours parti dans tout les sens sans aboutir nul part et sans jamais rien finir. A mi chemin d'un fonctionalité pan on changeait de sujets pour aller explorer un autre chemin. Ca a durée une décénie et au final ca a gavé tout le monde y compris son auteur. | |
| yos | 13-Jun-2012/14:42:36+2:00 |
| salut, merci pour les explications 1) il faut garder l'accès aux events de manière clean dans ma fonction do-user-data je sauvegarde les fonctions du feel objet puis insère les miènnes qui appele mes events maison : on-init: on-return: none on-show: on-draw: on-hide: none on-over: on-away: none on-down: on-up: on-alt-down: on-alt-up: on-down-over: on-down-away: on-alt-down-over: on-alt-down-away: on-time: on-scroll-line: none on-close: on-menu: on-key: on-move-away: none ensuite je rappele les fonctions feel de base sauvegardées precedement avec l'events recu et déjà traiter par les on-xxxx ces fonctions on-xxxx sont des redraw, detect etc et prenne en argument les mêmes paramètres que les redraw detect etc... 2) au sujet de la widget test formaté je croyais que quelqu'un en avait fait une (un vieux reboler francais ?) comment fonctionnait t'elle ? parse de html comme en python/qt ou dialect maison ? Rebol est si riche qu'on n'aura jamais fini de l'explorer ! merci. yos | |
| didec | 15-Jun-2012/13:16:56+2:00 |
| Salut Yos J'en ai fait une avec un dialecte maison tres semblable a ce que R3 propose dans son champ Richtext. http://membres.multimania.fr/didec/rebsite/styles/rtd-style/ | |
| coccinelle | 19-Jun-2012/10:57:22+2:00 |
| J'avais aussi écrit une ébauche, tu trouveras le code ici : http://www.digicamsoft.com/cgi-bin/rebelBB.cgi?thread=%3C29Dec200802202322377100%3E | |
| shadwolf | 15-Aug-2012/5:58:27+2:00 |
| didec si le mieux que RMA peu pondre c'est un mauvaise repompe de rtd-style de 2001 c'est triste a pleurer non ? rtd-style etait basé sur du widget compositing ... ce qui est lent et lourd en memoire comparer a area-tc. | |
| shadwolf | 15-Aug-2012/6:05:41+2:00 |
| RMA-GUI c'est un beau boxon et c'est pas pres d'etre intégré par defaut dans r3 de toute facon r3-alpha pour un bon moment encore. quand tu pense que rebgui c'etait tout integré direct une ligne de commande pan installer sur ton pc et près a l'emploi. RMA-Gui c'est ni fait ni a faire. Evidement c'est trop demander que les gens qui ont demandé des fonctions dínstallation automatique dans rebgui et qui font parti de RMA les integres a RMA-GUI. Comme si c'etait super dur. Enfin quand tu vois comment ils lute sur les ascenseurs et le resize des elements dans la fenetre c'est un peu normal que ca avance pas et que ca reste embrionaire. | |
| shadwolf | 15-Aug-2012/6:07:45+2:00 |
| si je m'ecoutait je reprendrai rebgui 0.38. RMA-GUI toujours pas de documentation a la hauteur de ce qu'a produit rebgui et pas non plus de liste des gob que contiendra a terme RMA-GUI | |
| shadwolf | 15-Aug-2012/6:52:28+2:00 |
| hum interessant de relire le code rtd-style de didec... je me doutait pas que area-tc en etait aussi proche. rtd-style est read et area-tc est ecrivable. rtd-style a pour but de se servir un maximum des attribus des widgets pour faire la composition du texte calculet l'emplacement du texte a dessine dans la ligne se fait avec carret-to-offset dans une widget prototype, ce qui est pas uninterressant quand on sait que c'est une partie qui m'a vraiment poser ennormement de probleme dans area-tc cette approche est plutot cool. l'autre difference c'est que rtd-style a pour but directement d'afficher du texte avec des fonts changeantes,rtd-style est un hybride entre le tout draw de area-tc et le tout widgets composé de mdp-gui. dans l'histoire des moteur de rendu de texte on a le widget compose (on configure une widget text pour afficher le text telqu'on le souhaite et on la colle dans une widget dont le but est de contenir les widgets les une a cote des autres c'est exactement comme decouper des mots,ou des lettres, dans les pages d'un magazine, et de les coller sur une grande page blanche) makedoc-gui et mdp-gui les premiere version de rebgui utilisent se principe. Puis on a le dessiner dans une grande widget en se servant de draw et d'une widget type pour connaitre la taille du texte et la disposition des elements de texte dessiner par draw. Et pour finir on a area-tc tout est dessiné par draw on se sert pas de widget intermediaire pour evaluer la taille des elements la tailles des elements est fixe sur l'ensemble du text et a peut pres calculer a la louche mais c'est editable. On se sert de deux tampon de texte un avec le text original l'autre avec le text + les instrcutions draw.dommage que ca n'est pas evolué plus avant la determination de la taille du texte ayant ete un probleme pour area-tc la method d'evaluation de rtd-style.r aurait pu etre employee comme optimisation on se serai servi d'une table d'indexe de taille pour savoir de combient de pixel bouger exactement le curseur pour atteindre le prochain caractere. Pour evite d'avoir a recalculer a la voler systematiquement la taille d'un element ce qui aurait en plus permis de faire varier la taille et le style de la police du texte du coup. Hello world aurait ete representer par [ 12 5 2 2 5 7 9 7 7 2 7] c'est plus ou moins ce qu'un algorithme compliquer dans area-tc fait a peu pres mais bon c'est de l'a peu pres ce qui fait qu'on a des probleme de texte qui se deplace trop etc.. La on aurait eu les vraie valeure exacte en pixels de chacque lettres. D'autres chose comme le texte clickable (lien hypertexte) ou l'integration d'images voir l'integration de dessin vectoriels auraient put etre les evolutions suivantes. Bref vu que c'est plus ou moins mort que dans le domaine on prefere revenir en arriere c'est pas pres d'avancer. | |
|
Login required to Post. | |