A propos de VID3

A propos de VID3
guest2	29-Sep-2008/18:37:13+2:00
Voilà quelques idées qui pourraient (selon moi) être implémentées dans VID3. Certaines sont annoncées, d'autres pas. 1/un méchanisme d'héritage et de surcharge de styles (Carl en a parlé mais pas de nouvelles). L'intérêt est évident. - Styles plus concis. - simplicité pour modifier dynamiquement les styles en modifant seulement un ancêtre. - inconvénient, c'est plus lent mais comme ce serait un mécanisme facultatif, libre au développeur de l'utiliser ou pas. il suffirait d'ajouter un verbe (is) dans le dialecte pour l'activer. ex: >> image 100x100 is box 2/Un mécanisme simple pour dumper, dupliquer, modifier les styles . Un tel mécanisme est prévu mais si je me base sur ce qui a été proposé dans la première version de VID3, c'est encore bien trop lourdingue. Je pense plutôt qu'il faudrait qu'un style soit complètement construit à plat dans une série de blocks imbriqués plutôt que dans une combinaison d'objets reliés et nécessitant des fonctions accessors et constructors. Je m'explique. Dans ma vision on définit un style comme suit: button: [ text "..." size 100x20 offset 0x0 color blue click [print "click"] over [color red] resize [grow xy] ... ] Il s'agit d'une série de blocks imbriqués préfixés soit par ce qui correspondra à une propriété soit par un nom d'êvenement. pour dumper un style, il suffit de faire un probe. pour modifier un style, il suffit d'utiliser un path, pas besoin d'accessors. >>button/size: 50x20 >>button/click: [print "bonjour"] pour duppliquer un style, il suffit de faire un copy/deep 3/ accès dynamique en lecture et modification aux propriétés des styles. Dans cette vision, il n'y plus de fonction spécifique pour construire (plus de init) de telle ou telle face à partir d'un style. Une face exploite directement les propriétés de son (ou ses) styles, en allant piocher directement dans les styles-block. Les propriétés d'une face ne sont plus construites à l'initialisation mais sont piochées à la demande dans le block même du style. C'est difficile à expliquer mais en gros on a affaire à des blocks, plus à des objets. les propriétés sont maintenues dans un block et non plus uniquement dans la face affichée. si j'affiche un bouton définit ainsi. view [ mon-bouton: [ is button text "c'est mon bouton" click [halt] ] ] la face et les gobs correspondants vont directement pointer sur le block qui est associé à mon-bouton. Et si par exemple je clique sur ce bouton, ce n'est pas une fonction scopée sur l'objet qui sera déclenchée mais bien le sous block [halt] qui sera executé. Ce mécanisme permet de modifier simplement n'importe quelle propriété dynamiquement sans avoir à connaitre comment le style est construit dans sa phase d'initialisation puisqu'il n'y a plus de phase de construction, tout est dynamique. si je veux modifier dynamiquement ce que fait mon-bouton quand je clique dessus, je n'ai qu'à taper: mon-button/click: [print "ici"] ou si la propriété n'existe pas encore, avec un append dans le block. Les propriétés offset et size sont également maintenues dans le block dynamiquement (elles le sont toutes, j'ai dit ). C'est très utile pour construire graphiquement un style. Car il suffit de faire un probe du block pour récupérer toutes les propriétés utiles d'une face à un instant T. Bon je vais pas plus m'étendre même si y'a beaucoup à dire encore. Une dernière chose, on pourrait craindre une certaine lenteur du au mécanisme de maintenance des propriétés dans les blocks. A chaque déclenchement d'event sur une face, l'event-handler doit aller voir dans le block correspondant si cet event est défini. (il doit aller voir aussi dans les blocks des styles hérités si il ne trouve pas la propriété localement) Mais en fait c'est pas si lent que ça par rapport aux bénéfices (j'ai fait des tests). 4/ j'ai oublié d'autres propositions mais ça reviendra.
Didec	29-Sep-2008/18:48:20+2:00
Ok, mais le code qui gère l'accès à ces données, je ne vois pas trop comment il peut être le même quel que soit le type de l'objet (bouton, field, table, menu...). Comment pensais-tu organiser cela ?
guest2	29-Sep-2008/19:12:20+2:00
en fait (je sais pas si ça répond à ta question) je définis une liste de primitives (fonctions) qui sont les accesseurs communs. L'idée est qu'on peut tout faire à partir de ces primitives. Il y a une primitive par event et une par propriété. Plus quelques autres. Ensuite on peut intégrer le code rebol qu'on veut si aucune primitive n'existe pour ce qu'on veut faire. par exemple, je te montre 2 styles de mes tests. Title-bar [ text "Title" offset 0x0 size -1x20 color sky drag [parent [move xy]] resize [grow x] ] window [ offset 50x50 size 50x50 color snow click [print "click"] has title-bar [text "Title window"] has content [ offset 3x20 size -1x-1 - face/offset color snow resize [grow xy] ] has resize-box [ size 15x15 offset (face/parent-face/size - face/size) color sky drag [parent [grow xy]] resize [move xy] over [color red] ] has resize-bar-left [ offset 0x0 size 3x-1 color sky drag [parent [grow -1 * x move x]] resize [grow y] ] ] Le Title-bar est un style qui prend automatiquement la largeur de son contenant. Lorsqu'on le drag, il déplace son parent au lieu de se déplacer lui même. C'est le sens du drag [parent [move xy]]. 'parent et 'move sont 2 primitives. Et lorsqu'il reçoit un evenement resize, il croit en fonction de la largeur. resize [grow x] 'grow est également une primitive Dans le style window, tu peux voir que je fais référence au style Title-bar et que je définis aussi assez facilement des bars pour redimmensionner le style window en utilisant ces même primitives. ces primitives sont des fonctions. En gros quand un event est déclenché, l'event-handler regarde si il existe un block associé à l'event dans la face et l'execute, peu importe ce qu'il contient.
guest2	29-Sep-2008/19:54:28+2:00
hmmm... J'ai relu ton message. tu demandes comment on accède aux données saisies. Je n'ai pas beaucoup réflechi à cet aspect des choses. Mais il me semble qu'on y accède comme à n'importe quelle autre propriété du style-block. En tapant le path complet. si j'affiche un style du genre: has Desk [ ... has My-window [ ... has field-name [ is field text "****" ... ] ... ] ... ] je dois pouvoir obtenir ou modifier le contenu du champs field-name, en utilisant le path >>desk/my-window/field-name/text
guest2	29-Sep-2008/23:08:47+2:00
En parlant du loup, Carl commence à poster son travail sur VID3 dans le wiki. http://www.rebol.net/wiki/GUI_Faces Il devrait poster aussi sur son blog incessemment sous peu. Dans les jours qui viennent, pas mal de nouveautés devraient apparaitre ici: http://www.rebol.net/wiki/Special:Recentchanges C'est assez succint, difficile donc de se prononcer sur le nouveau VID3 pour le moment.
shadwolf	16-Oct-2008/19:15:42+2:00
ca fait longtemps que carl a posté ca avant meme sa désision d'abandonner la version proposée par gabriele (VID3.4) et de tout refondre et depuis qu'il a pris cette décision curant du moi d'août on a rien de très précis sur ce que serra le nouveau VID qu'on doit plus appellé VID et qui n'a pas de nom. Enfin pas très net et pas très motivant tout ça.
Login required to Post.